DEV Community: Ardiansyah Sulistyo

A coding assistant drafted my Nginx config. Here’s what I still had to verify

Ardiansyah Sulistyo — Sat, 05 Sep 2026 08:59:43 +0000

I asked a coding assistant to draft an Nginx config for a small Laravel app on an Ubuntu VPS.

It produced something usable in seconds.

That is the useful part. The dangerous part is that a config can look completely reasonable, pass a quick visual scan, and still be wrong for the actual server.

The assistant does not know my installed PHP version, the PHP-FPM socket on the machine, my directory layout, whether DNS already points at the VPS, or which headers my app and proxy setup need. It can make sensible guesses. Production infrastructure is where sensible guesses need to become verified facts.

This is the review process I use before I let an AI-drafted Nginx config anywhere near a live site.

The starting point

The setup is intentionally boring:

Ubuntu VPS.
Nginx as the public web server.
A Laravel app in /var/www/myapp.
PHP-FPM handling PHP requests.
A non-root deploy user owning the app code.

A typical AI-generated starting point looks roughly like this:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/myapp/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

There is nothing obviously bad about it. In fact, this is close to what I would write manually.

But “close” is not the same as correct.

1. I verify the document root

For Laravel, the Nginx root must point to the public directory:

root /var/www/myapp/public;

Not:

root /var/www/myapp;

This is an easy detail for an assistant to get right, but I still check it because a wrong root can expose files that should never be served publicly: .env, source code, Composer files, or internal directories.

On the server, I verify the path exists and contains Laravel’s entry point:

ls -la /var/www/myapp/public

I expect to see index.php there.

I also check the app’s actual deployment path instead of assuming it matches the example. A config generated for /var/www/app does not magically become correct because I pasted it into a file named myapp.

2. I verify the actual PHP-FPM socket

This is probably the most common “looks fine but returns 502” problem.

An assistant may assume:

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

But the server might have PHP 8.1, 8.3, or a custom pool/socket configuration.

Before using the config, I check what exists:

ls -la /run/php/

I might see:

php8.3-fpm.sock
php8.3-fpm.pid

In that case, the Nginx config needs:

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

I also confirm PHP-FPM itself is healthy:

sudo systemctl status php8.3-fpm

The exact service name depends on the installed version. This is why I do not trust a hard-coded PHP version from an AI response, a blog post, or an old config copied from another VPS.

3. I verify `server_name` and the default site

A correct server block can still be ignored if Nginx does not match the incoming host header.

I check the intended domains:

server_name example.com www.example.com;

Then I make sure the DNS records point to the VPS before treating the domain test as meaningful.

I also disable the default Nginx site once my own server block is ready:

sudo rm /etc/nginx/sites-enabled/default

That is optional if I deliberately want the default site, but leaving it enabled has confused me more than once during initial setup. A request can hit the default virtual host instead of the app and make it look as though the app config is broken.

To inspect what Nginx is actually loading, I use:

sudo nginx -T

For a faster targeted check:

sudo nginx -T | grep -A 15 'server_name example.com'

That is more useful than staring at the file I intended to enable. The effective configuration is what matters.

4. I verify the Laravel routing rule

This line is the core of a normal Laravel Nginx setup:

try_files $uri $uri/ /index.php?$query_string;

It lets Nginx serve real static files directly and forwards routes that do not map to files into Laravel’s front controller.

Without it, routes such as:

https://example.com/dashboard
https://example.com/settings/profile

can return 404 even though they work locally through Laravel’s development server.

I test at least:

The home page.
One regular application route.
A static asset such as CSS or an image.
A route with query parameters, if the app uses them.

A generated config can be syntactically valid and still miss the behavior the framework expects.

5. I verify ownership and writable directories

Nginx does not run Laravel alone. PHP-FPM executes PHP requests, and Laravel needs write access to some directories.

For a typical Laravel deployment, I check:

sudo chown -R deploy:deploy /var/www/myapp
sudo chmod -R ug+rwx /var/www/myapp/storage /var/www/myapp/bootstrap/cache

The right ownership model depends on how PHP-FPM is configured on the server. I do not treat the commands above as universal copy-paste instructions.

What I actually verify is:

Which user owns the application files.
Which user/group PHP-FPM workers run as.
Whether the application can write to storage/ and bootstrap/cache/.
Whether I have accidentally made the whole project world-writable just to make an error disappear.

If Laravel shows a generic 500 error after Nginx is configured, I check the Laravel log before changing random Nginx directives:

sudo tail -n 100 /var/www/myapp/storage/logs/laravel.log

A permissions issue often looks like an application error, not an Nginx error.

6. I add proxy headers only when the app is behind a proxy

For a Laravel app served directly by PHP-FPM, I do not need a proxy_pass block.

For a Node app behind Nginx, I do. The basic pattern is:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Those headers are not decorative. They affect what the application sees as the request host, client address, and original scheme.

I check whether the app needs to trust its proxy before assuming HTTPS URLs, redirects, or secure cookies will behave correctly. This is especially important if TLS terminates at Nginx or another layer in front of the app.

7. I do not let the assistant “solve” TLS by guessing

The first Nginx config often listens on HTTP only:

listen 80;

That is fine as an initial step. It is not the final state for a public application that handles login or user data.

I usually get HTTP working first, then configure TLS with a certificate provider such as Let’s Encrypt. The exact commands and configuration depend on the domain, DNS state, firewall rules, and whether another proxy/CDN is involved.

This is a good example of where an AI response can be dangerously confident. It may tell you to paste a certificate path that does not exist yet, redirect all traffic before certificate issuance succeeds, or assume a particular Certbot setup.

My rule is simple: treat the TLS instructions as a plan to verify, not a deployment command to paste blindly.

8. I test before every reload

Before I reload Nginx, I run:

sudo nginx -t

If it passes:

sudo systemctl reload nginx

Then I test the response:

curl -I http://example.com

Once HTTPS is configured:

curl -I https://example.com

I also keep an eye on logs while testing:

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

For an app-specific setup, I prefer separate logs:

access_log /var/log/nginx/myapp-access.log;
error_log /var/log/nginx/myapp-error.log;

Then I can debug one site without digging through unrelated traffic from every server block.

What AI was actually useful for

The coding assistant was useful as a fast first draft. It helped me get a standard config shape without opening old repositories or searching for a template.

It was less useful as an authority on the live server.

The work that still mattered was:

Matching paths to the actual deployment.
Checking the installed PHP-FPM version and socket.
Confirming DNS and Nginx virtual-host selection.
Verifying application permissions.
Testing framework routes, static files, and error behavior.
Reading the actual server and application logs.

That is not a criticism of coding assistants. It is just the boundary I try to keep clear: they can draft infrastructure configuration, but they cannot know my machine better than the machine itself.

My small review checklist

Before I accept an AI-drafted Nginx config for a Laravel app, I check:

Does root point to the Laravel public/ directory?
Does fastcgi_pass match a real PHP-FPM socket on this server?
Does server_name match the actual domain, and does DNS point here?
Is the intended site enabled, and is a default site catching my request instead?
Does try_files route application URLs through index.php?
Can the app write to storage/ and bootstrap/cache/ without unsafe permissions?
Did I run sudo nginx -t before reloading?
Did I test a real request and inspect the relevant logs?
Is TLS configured and verified before I treat the site as ready?

The assistant can write the first 80% of a config in a few seconds. The remaining 20% is where production incidents tend to hide.

What infrastructure changes do you let coding assistants make directly, and what do you always verify by hand?

Deploying Next.js on a VPS: The 12 Things Nobody Tells You

Ardiansyah Sulistyo — Thu, 03 Sep 2026 12:25:03 +0000

Moving a Next.js app off Vercel and onto a plain Ubuntu VPS usually starts with a painful realization: either your serverless functions are timing out on background jobs, or your client just handed you a strict "you must host this on our infrastructure" requirement.
Deploying the app itself is easy. What trips people up (and what cost me hours of debugging and locking myself out of my own server) is everything around the app.
Here are the 12 things that actually break when you leave the serverless ecosystem, in the order you'll hit them.

1. Next.js needs a process manager, not just `npm start`

Running npm start in a terminal dies the moment you disconnect. You need
something that keeps the process alive, restarts it on crash, and survives
a reboot. PM2 is the simplest option for a single-server Node deploy.

npm install -g pm2

// ecosystem.config.js
module.exports = {
  apps: [{
    name: "my-app",
    script: "node_modules/.bin/next",
    args: "start",
    cwd: "/var/www/my-app",
    instances: 1,
    exec_mode: "fork",
    autorestart: true,
    max_memory_restart: "512M",
    env: { NODE_ENV: "production", PORT: 3000 },
  }],
};

cd /var/www/my-app && pm2 start ecosystem.config.js
pm2 save
pm2 startup systemd -u YOUR_USER --hp /home/YOUR_USER

That last line is the one people forget - without it, PM2's process list doesn't survive a server reboot.

2. Nginx needs to proxy to the port, not serve the files

Next.js is not a static site (unless you've explicitly exported it as
one). Nginx's job is to forward requests to the Node process, not serve
files from disk:

upstream nextjs_upstream {
    server 127.0.0.1:3000;
    keepalive 64;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://nextjs_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support - required for HMR and any realtime features
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

3. Forgetting the WebSocket upgrade headers breaks more than dev mode

proxy_set_header Upgrade $http_upgrade; and Connection "upgrade" aren't
just for Fast Refresh in development. Any app using WebSockets or
Server-Sent Events in production (chat, live notifications, streaming AI
responses) silently breaks without these two lines. This is one of the
most common "works locally, broken in prod" bugs.

4. `client_max_body_size` - the silent 413 error

Nginx defaults to a 1MB request body limit. File uploads, image processing
endpoints, and some API routes will fail with a 413 Request Entity Too Large - and only in production, since your local dev server has no such
limit. Set it explicitly:

client_max_body_size 25M;

5. `proxy_buffering off` for streaming responses

If you're streaming a response (Server-Sent Events, streaming LLM
completions via the Vercel AI SDK, etc.), Nginx's default buffering will
hold the entire response before sending it to the client - defeating the
purpose of streaming. Turn it off for the relevant location block:

proxy_buffering off;

6. DNS propagation is the #1 cause of "SSL setup failed"

Before running Certbot, verify your domain's A record actually points at
the server:

dig +short example.com
# should print your server's public IP

If it doesn't match, Certbot's HTTP-01 challenge will fail - not because
of a config error, but because Let's Encrypt can't reach your server at
that domain yet. This single check saves more support tickets than
anything else on this list.

7. UFW must allow SSH before you enable it

This one is a rite of passage:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable   # only after the rules above are in place

Enable UFW before allowing SSH and you'll lock yourself out of your own
server. Always add the SSH rule first.

8. Certbot's Nginx plugin edits your config for you - read the diff

sudo certbot --nginx -d example.com -d www.example.com \
    --agree-tos -m you@example.com --redirect

This adds the SSL server block, the HTTP→HTTPS redirect, and the
certificate paths automatically. Run nginx -t afterward to confirm it's
still valid, and glance at /etc/nginx/sites-available/example.com once
so you know what changed.

9. Certbot renewal isn't automatic until you verify it

Certbot installs a systemd timer, but "installed" isn't the same as
"working." Verify it explicitly:

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

If the dry run fails, your certificate will expire in 90 days without
you knowing until browsers start showing warnings to your users.

10. Fail2Ban's default backend breaks on Ubuntu 24.04

Ubuntu 22.04 and earlier used file-based auth logs (/var/log/auth.log).
24.04 moved logging fully to the systemd journal. If your Fail2Ban jail is
still configured for the file backend, it silently monitors a log that
barely gets written to - and bans nothing.

# /etc/fail2ban/jail.d/sshd.local
[sshd]
enabled = true
backend = systemd
maxretry = 4
findtime = 10m
bantime = 1h

Verify it's actually watching:

sudo fail2ban-client status sshd

11. `next/image` is agonizingly slow without `sharp`

On Vercel, image optimization just works. On a raw VPS, if you use the <Image /> component without installing sharp, Next.js falls back to a purely JavaScript-based image optimizer. It is incredibly slow and eats up your CPU.

npm install sharp

Add it to your production dependencies. If you don't, your $6 VPS will easily spike to 100% CPU utilization just trying to serve a few optimized avatars.

12. Your app builds fine locally and OOMs on a 1GB VPS

next build on a $6/month 1GB RAM droplet frequently gets killed by the
OOM reaper mid-build - with no clear error, just a dead process. If you
don't have a CI pipeline building elsewhere, add swap before your first
build:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

The checklist, if you're tired of doing this manually

I got tired of locking myself out of UFW, forgetting to set the WebSocket headers, and missing the systemd fixes. So, I bundled this exact Next.js setup (Nginx vhost, UFW, Fail2Ban, Swap, and Certbot) into a single bash script.

I also added one thing this checklist can't: a Telegram notification the moment anyone logs into the server over SSH.

You can grab the ServerSecure Setup here.

This article is the complete free version of the checklist - nothing here is paywalled. The script is just for when you'd rather spend those 15 terminal commands building your actual product.

Running into something not covered here? Drop it in the comments - I'll add it to the list.

Get a Telegram Notification Every Time Someone SSHes Into Your Server

Ardiansyah Sulistyo — Wed, 02 Sep 2026 07:23:32 +0000

A fresh VPS starts receiving SSH brute-force attempts within minutes of
going public. Most of us find out about a breach after the damage -
a spike in outbound traffic, a suspended hosting account, a client asking
why their site is serving spam.

What if you just... knew? The second someone authenticates?

Here's a complete, working setup that sends a Telegram message to your
phone every time a user successfully logs in over SSH - key or password,
interactive or automated. It's about 30 lines of Bash plus one line of PAM
config. No agent, no daemon, no third-party service beyond Telegram's free
Bot API.

How it works

SSH login events pass through PAM (Pluggable Authentication Modules)
on Linux. PAM has a module called pam_exec that can run an arbitrary
script at specific points in the auth lifecycle - including
open_session, which fires only after a successful login.

/etc/pam.d/sshd
  └─ pam_exec (open_session) ──▶ /usr/local/bin/ssh-notify
                                       └─ curl → Telegram Bot API

That's the entire architecture. No polling, no log-tailing, no extra
processes running in the background.

Step 1 - Create a Telegram bot (2 minutes)

Open Telegram, search for @botfather
Send /newbot, follow the prompts, name it whatever you like
Copy the token it gives you - looks like 123456789:ABCdefGHIjklMNOpqrSTUvwxYZ

Now get your chat ID:

Send any message to your new bot
Visit https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates in a browser
Find "chat":{"id":YOUR_CHAT_ID} in the JSON response

That's it - no app registration, no OAuth flow, no approval process.

Step 2 - Store the credentials securely

sudo mkdir -p /etc/serversecure
sudo tee /etc/serversecure/telegram.conf > /dev/null <<'EOF'
BOT_TOKEN="123456789:ABCdefGHIjklMNOpqrSTUvwxYZ"
CHAT_ID="987654321"
EOF
sudo chmod 600 /etc/serversecure/telegram.conf
sudo chown root:root /etc/serversecure/telegram.conf

Mode 600, owned by root - the bot token is effectively a password.
Never commit this file to version control.

Step 3 - The notification script

Save this as /usr/local/bin/ssh-notify:

#!/usr/bin/env bash
# ssh-notify - Telegram SSH login alert via pam_exec
#
# CRITICAL: this script MUST exit 0 under all circumstances.
# A non-zero exit code from a pam_exec hook can block the login.

readonly CONF_FILE="/etc/serversecure/telegram.conf"
readonly STATE_DIR="/var/lib/ssh-notify"

main() {
    # Only fire on successful login, not on session close
    if [[ "${PAM_TYPE:-}" != "open_session" ]]; then
        return 0
    fi

    [[ -f "${CONF_FILE}" ]] || return 0
    # shellcheck source=/dev/null
    source "${CONF_FILE}"
    [[ -n "${BOT_TOKEN:-}" && -n "${CHAT_ID:-}" ]] || return 0

    # --- Rate limiting: collapse repeat alerts within 60s ---
    # Tools like VS Code Remote SSH or rsync open multiple sessions per
    # connection. Without this, one "login" becomes four notifications.
    local user="${PAM_USER:-unknown}"
    local rhost="${PAM_RHOST:-unknown}"
    local key
    key=$(echo "${user}@${rhost}" | tr -c '[:alnum:]@.' '_')
    local state_file="${STATE_DIR}/${key}"

    if [[ -f "${state_file}" ]]; then
        local last now elapsed
        last=$(cat "${state_file}" 2>/dev/null || echo 0)
        now=$(date +%s)
        elapsed=$(( now - last ))
        [[ "${elapsed}" -lt 60 ]] && return 0
    fi
    mkdir -p "${STATE_DIR}" 2>/dev/null
    date +%s > "${state_file}" 2>/dev/null

    # --- Build the alert ---
    local host ip
    host=$(hostname)
    ip=$(curl -sf --max-time 3 https://ifconfig.me 2>/dev/null || echo "unknown")

    local message="🔐 *SSH Login Alert - ${host}*

🖥️ Server: \`${host}\` (\`${ip}\`)
👤 User: \`${user}\`
🌐 Source IP: \`${rhost}\`
🕒 Time: $(date -u '+%Y-%m-%d %H:%M:%S UTC')"

    # --- Send it async, hard-timeout, never block the login ---
    (
        setsid curl -sf --max-time 5 \
            -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
            -d "chat_id=${CHAT_ID}" \
            -d "parse_mode=Markdown" \
            --data-urlencode "text=${message}" \
            >/dev/null 2>&1
    ) &

    return 0
}

main
exit 0

sudo chmod 755 /usr/local/bin/ssh-notify
sudo chown root:root /usr/local/bin/ssh-notify

Three design decisions worth calling out, because they're the difference
between "cool script" and "thing you can trust in production":

It always exits 0. A pam_exec hook that returns non-zero can be configured to block the login it's supposed to be reporting on. This script fails silently, always, no exceptions.
The curl call runs in a detached subshell (setsid ... &). If Telegram's API is slow or your network hiccups, your SSH login is never delayed waiting on it.
Rate limiting by IP+user. Without this, tools that open multiple SSH channels per "connection" (VS Code Remote is the worst offender) will spam you with 3-4 notifications for what is, to you, one login.

Step 4 - Wire it into PAM

echo "session    optional     pam_exec.so   seteuid /usr/local/bin/ssh-notify" | \
    sudo tee -a /etc/pam.d/sshd

The optional control flag is important - it tells PAM this module's
success or failure has no bearing on whether the login proceeds.

Restart nothing - PAM config is read per-session, so your next SSH login
will trigger it. Test with a login from another terminal window; you
should get a Telegram message within a couple of seconds.

What this doesn't cover (and what would)

This gets you real-time visibility. It doesn't get you:

Geolocation on the source IP - doable with a free IP lookup API, left out here to avoid a third-party dependency by default (and for privacy - you're now sending login IPs to another service).
"New device" flagging - tracking previously-seen IPs and flagging first-time sources needs a small persistent IP list, easy to add.
Fail2Ban ban alerts, sudo usage alerts, disk-full alerts - same pattern, different trigger. PAM's pam_exec only covers auth events; these need to hook into sudo's own PAM stack or a cron check.

If you want all of that plus the rest of the hardening that should happen
before you ever expose SSH to the internet - non-root user setup, UFW,
Fail2Ban jails, automatic SSL - that's the larger tool this is one module
of: ServerSecure Setup. This snippet is the full
signature feature, free, because it costs me nothing to give away and it's
the best proof I can offer that the rest of the tool is built with the
same care.

Questions or found an edge case? Drop a comment - I read and reply to
every one.

Why Most Cafe Websites Feel Outdated (And How I Fixed It)

Ardiansyah Sulistyo — Tue, 19 May 2026 08:09:52 +0000

Most cafe websites still look like generic business templates from 2016.

Bright backgrounds, cluttered layouts, autoplay sliders, weak typography, and mobile experiences that feel like an afterthought.

I wanted to create something that feels modern, cinematic, and mobile-first — more like a premium app experience than a traditional website.

So I built Noir & Brew, a premium Astro landing page template for modern coffee shops and creative F&B brands.

The Problem With Most Cafe Websites

Most cafe websites follow the same pattern:

Generic layouts
Poor mobile navigation
Weak visual hierarchy
Overcrowded sections
Inconsistent branding
Slow performance
Outdated UI patterns

The result?

They don’t feel memorable.

And for cafes, atmosphere matters just as much as the product itself.

A website should communicate the same feeling customers get when they walk into the space:

warm lighting
premium ambiance
calm atmosphere
intentional branding

That became the core direction behind this project.

Designing Around Atmosphere

Instead of focusing only on information density, I focused on visual mood and presentation first.

The design direction was inspired by:

editorial layouts
luxury hospitality brands
cinematic dark interfaces
premium coffee packaging
modern mobile app navigation

I intentionally used:

dark backgrounds
warm gold accents
oversized typography
immersive cards
spacious layouts
minimal UI noise

The goal was simple:

Make the website feel premium before users even start reading.

Mobile-First Was the Priority

Most restaurant traffic comes from mobile devices.

But many templates still treat mobile as a scaled-down desktop layout.

I did the opposite.

I designed the mobile experience first:

bottom navigation
app-like interaction
compact content blocks
thumb-friendly spacing
immersive promo sections
simplified menu browsing

Only after the mobile structure felt complete did I expand the design into desktop.

That decision alone made the experience feel significantly more modern.

Tech Stack

I wanted the template to stay lightweight while still feeling interactive.

Stack Used

Astro
React
Tailwind CSS v4
Framer Motion

Why Astro?

Astro gives excellent performance out of the box while still allowing interactive islands where needed.

That means:

fast initial load
less JavaScript shipped
SEO-friendly pages
smoother interactions

For content-focused websites like cafes, portfolios, and hospitality brands, this architecture works extremely well.

Features

The template currently includes:

Responsive landing pages
Mobile-first layouts
Interactive menu section
Promo showcase
Contact & location pages
3 built-in themes
SEO-ready structure
Easy customization
Production-ready codebase

Designed for:

cafes
coffee shops
restaurants
hospitality brands
creative studios

Challenges During Development

One of the hardest parts was balancing aesthetics with readability.

Dark luxury interfaces can easily become:

too low contrast
visually noisy
difficult to scan

I had to simplify multiple sections repeatedly before the interface finally felt clean enough.

Another challenge was avoiding over-animation.

Modern websites often animate everything.

Instead, I focused on:

subtle transitions
layered depth
hover feedback
visual rhythm

That helped the UI feel calmer and more premium.

Final Thoughts

I think websites for physical spaces should feel emotional — not just functional.

Especially for cafes.

People don’t only buy coffee.

They buy atmosphere, identity, and experience.

That’s what I tried to translate into this template.

Live Demo

🔗 Demo:
Noir & Brew Demo

🔗 Gumroad:
Noir & Brew Template

I built a minimal company profile template because I was tired of colorful noise

Ardiansyah Sulistyo — Fri, 20 Feb 2026 07:33:36 +0000

🔗 Live demo: https://mono-profile-alpha.vercel.app/

I have a problem with most website templates.

They're loud. Gradients everywhere, hero sections with three different
typefaces, accent colors fighting each other. I get it they want to
look impressive in a marketplace thumbnail.

But when I actually need to use one? It's exhausting.

I like monochrome. Black, white, grays, maybe one muted accent.
Clean type. Room to breathe. So after saying "I'll just build my own"
for the fifth time, I actually did.

This is MONO, a minimal company profile template I built for myself
and ended up packaging for anyone else who thinks the same way.

The stack

I went with what I'm comfortable with, and what I'd actually want
to inherit from someone else:

Vite — fast dev server, no config hell
React + TypeScript — predictable, easy to extend
Tailwind CSS — utility-first, no surprise CSS specificity
shadcn/ui — accessible components without opinionated styling

Shadcn was actually the right call here. Since the components are
unstyled by default and live in your codebase, the monochrome
aesthetic doesn't fight the component library. You're not overriding
a blue primary button everywhere.

What's in the template

It's a typical company profile page, but intentionally stripped down:

Hero (headline, subtext, CTA)
Services / what you offer
Selected work / portfolio
About section
FAQ
Contact

That's it. No unnecessary animations, no scroll-jacking, no
"surprise me" interactions.

The section order makes sense for most businesses: tell me who you
are → what you do → proof you've done it → answer my obvious
questions → let me reach you.

The design decision I'm most glad I made

I almost added a color theme switcher. "Users can pick an accent
color!" Sounds useful, right?

I removed it.

Not because it's hard to build it's not. But it introduces
decisions. "Should I use purple or teal?" is exactly the kind of
question I want the template to eliminate, not create.

Monochrome is a decision. Stick to it.

If you want a specific accent later, you change one Tailwind CSS
variable and you're done. That's intentional.

Who this is for

Honestly? Anyone who needs a company profile that looks professional
without spending a week on design decisions.

That includes:

Agencies putting together a quick client-facing profile
Freelancers who want a site that looks serious
Developers who'd rather write code than pick color palettes
Someone building a startup landing page before they figure out branding

It's not a dashboard, not a SaaS template, not a landing page with
17 sections. Just a company profile. Done well.

If you want to grab it

It's on Gumroad: [https://aardnsyhs.gumroad.com/l/mono-company-profile]

Comes with the full source code, clean folder structure, and a README
that explains how to customize the key parts without touching
everything.

If you check it out or if you've built something similar I'd love
to hear what you think. What's the one thing you always end up
rebuilding when you use someone else's template?