Getting it online is still where most of those prototypes die. The app runs on localhost, the demo is a screen recording, and nobody else ever clicks on it. The feedback you actually need, from a real person using the real thing, never happens.

My answer to this has become boring on purpose: rent one small server, and set it up once, properly, so that every future idea is a subdomain away from being live.

Why a server, and not another platform

Hosting platforms are great until you have five experiments, a database, a background worker and a cache. Then you're juggling five dashboards, five free tiers and five sets of limits.

A small VPS costs about as much as a coffee a month and gives you:

• One place for everything. Ten prototypes, their databases and their queues, all on one box.

• Real URLs in minutes. idea-one.yourdomain.com, idea-two.yourdomain.com. Send the link, get feedback the same day.

• No surprises. No per-app pricing and no cold starts. Nothing gets paused because it's on a free tier.

• Understanding. You learn what "deployed" actually means, which makes you better at the rest of your job.

The catch, and the reason most people don't do this, is fear. And that fear is justified.

The internet will find your server in minutes

Put a server online and bots start knocking within minutes. They try passwords on SSH, look for open databases and hunt for admin panels. On my server, the logs showed bots probing the admin login page every single day.

Most "deploy to a VPS" tutorials open a web port, open a database port, put an admin panel on the internet, and call it done. It works, and it's also an open invitation.

So here is the setup I'm proposing instead. You don't need to become a DevOps engineer to run it. You just need to understand the picture.

The architecture, in one picture

Here are the five ideas that make this safe, without the jargon.

1. Your server has no front door

Normally, a web server waits for visitors to connect to it, so it has to leave a door open (ports 80 and 443).

With a Cloudflare Tunnel, the direction is flipped. A small program on your server, cloudflared, calls out to Cloudflare and keeps that line open. Visitors go to Cloudflare, and Cloudflare passes their requests down the line your server opened.

It's the difference between leaving your door unlocked for deliveries and phoning the courier yourself. Nothing on your server is waiting for strangers. Your server's real address never even shows up in DNS; anyone looking it up sees only Cloudflare.

The only door left open is SSH, and that one takes keys only, with no passwords and no root login.

2. A receptionist decides where each visitor goes

Traefik sits behind the tunnel and routes by name. idea-one.yourdomain.com goes to one container and idea-two.yourdomain.com to another.

This is the part that makes it great for prototyping. Launching a new idea means starting a container with a label that says which subdomain it answers to. There's no new server, no new certificate and no new firewall rule. Cloudflare handles HTTPS.

3. The receptionist doesn't get the master key

To know which containers exist, Traefik needs to talk to Docker. The obvious way is to hand it Docker's control socket. But full access to that socket is effectively root on your machine, and Traefik is the one component that talks to the internet all day.

So Traefik talks to Docker through a small guard (a "socket proxy") that only allows read requests: what's running, and on which subdomain. It can't create, start or change anything. If Traefik were ever compromised, the attacker would get a read-only view, not your server.

4. Databases live in a back room with no windows

Postgres and Redis sit on a private network that has no route to the internet, in either direction. Your apps can reach them, and nobody else can. The database also gets an account that can only work with its own tables, not an all-powerful admin account.

5. The admin panel isn't on the internet at all

Tools like Portainer are handy, but by design they can do anything to your server. Instead of putting a login page in front of that, take it off the internet entirely. It listens only on the server itself, and you reach it from your laptop through an SSH tunnel.

The strongest protection isn't a better lock. It's not having that door on the street at all.

The result: from the internet, my server has exactly one open port, SSH. There's no web port, no database port and no admin panel. Everything else comes in through the tunnel, gets routed by name, and lands in a container that can only reach what it needs.

"It's green" does not mean "it's safe"

This is the lesson I most want vibe coders to take away.

While building this, I found things that looked perfectly healthy and weren't protected at all:

• Redis was set up with a password, and its health check said healthy. It was actually accepting connections with no password, because it couldn't read its password file and treated the empty result as "no password required."

• The firewall said "deny everything," while Docker quietly bypassed it and exposed a port to the whole internet anyway.

• A setting that was supposed to stop the proxy from starting containers was switched on and simply didn't work.

None of these threw an error. AI-written setup scripts and copy-pasted tutorials fail the same way: the config reads correctly, the dashboard is green, and the door is open.

So the rule I now follow is: don't trust the config, test the behaviour. Knock on the door the way an attacker would, and see if it opens.

I turned the whole thing into a skill

I've packaged the whole thing as an AI agent skill: a set of instructions that an assistant like Claude Code follows to set this up on your server, with your domain. It asks you for the few things it needs, builds the setup step by step, and, most importantly, checks each step by actually trying to break it before it moves on.

I've tested it on a brand-new, empty server. About 30 minutes later it was hardened, my old site and database were restored onto it from a backup, and it was live, with every check passing.

You don't need to memorise the commands. What matters is understanding the picture above well enough to know when something is wrong. The skill handles the typing.

Try it on your own server

What you need

• A VPS with a fresh Ubuntu install (24.04 or newer). Any provider works, and the cheapest plan is plenty to start with.

• A domain whose DNS is managed by Cloudflare. The free plan is enough.

• An AI coding agent that supports skills, such as Claude Code, Cursor or Codex.

• SSH access to the server. If all you have is the provider's root password, the skill helps you switch to a key.

1. Install the skill (one command, on your laptop):

npx skills add anant-c/skills --skill vps-setup-for-vibe-coders

2. Ask your agent for it, in plain words:

"Help me set up my new VPS. The SSH alias is myserver and the domain is example.com."

3. Answer a few questions. Which domain, what you're deploying, and whether you want an admin panel. That's the whole interview.

4. Click twice in Cloudflare when it asks. First, create a tunnel and paste its token back to the agent. Second, add two routes, example.com and *.example.com, both pointing at http://traefik:80. Then switch on Always Use HTTPS.

5. Read the report at the end. The skill scans your server from the outside, where the only open port should be SSH, and runs a 19-point health check. Then it tells you plainly what it didn't cover, such as off-site backups.

After that, launching a new idea is one sentence to your agent: "deploy this app at idea-one.example.com."

Links

• On skills.sh: skills.sh/anant-c/skills/vps-setup-for-vibe-coders

• Source on GitHub: github.com/anant-c/skills

A skill runs with your agent's permissions, so read it before you run it. It's plain Markdown and takes about ten minutes to skim, and the traps file alone is worth reading.

This is the first of a series, if you want it

Here's what I want to build: one piece of infrastructure per post. First the intuition, explained so you don't need a CS degree to follow it. Then a skill that sets it up for you and proves it's safe by trying to break it.

Because vibe coding shouldn't force you to choose between shipping fast and shipping safe. Developers get to move faster. Vibe coders get to ship something real, not a demo held together by hallucinated config and a green checkmark that's lying to them.

What should I break down next?