Deploying a Claude Code or Cursor project to a Hetzner server the right way

If you built your app with Claude Code or Cursor instead of a platform like Lovable, you probably never had built-in hosting to begin with. That’s simpler in one way: there’s no platform sandbox to work around. Here’s the plain path from a fresh Hetzner server to your app running in production, with real HTTPS and no manual restart every time you deploy.

A quick note on cost first. Hetzner raised prices on its shared-vCPU line in June 2026, by a meaningful amount. Any number you saw in an older tutorial is probably out of date. Check Hetzner’s current pricing page before you commit.

Step 1: provision the server

Create a fresh Ubuntu 24.04 server on Hetzner Cloud. Pick a CPX tier sized to your app; a small app with modest traffic rarely needs more than the smallest shared-vCPU tier to start.

Step 2: harden it before anything else touches it

Do this before you install your app, not after.

# SSH keys only, no password login
sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

# Firewall: only 22, 80, 443
sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

# Automatic security updates
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# fail2ban to slow down brute-force attempts
sudo apt install -y fail2ban

Create a non-root user for deploys instead of using root for everything day to day.

Step 3: install Docker and Caddy

Docker runs your app in a container; Caddy sits in front of it and handles HTTPS automatically, with no certificate wrangling.

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

sudo apt install -y caddy

A minimal Caddyfile for a single app:

your-domain.com {
    reverse_proxy localhost:3000
}

That’s the entire TLS setup. Caddy requests and renews the certificate on its own.

Step 4: containerize your app

A basic Dockerfile for a Node app:

FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

Build and run it:

docker build -t my-app .
docker run -d --restart unless-stopped -p 3000:3000 --env-file .env my-app

Keep secrets in .env, passed at runtime. Never bake them into the image. Check this with docker history my-app. You should not see any secret value in the layer history.

Step 5: deploy without downtime

Here’s the simplest zero-downtime pattern for one server. Build the new image. Start it on a different port. Confirm it’s healthy. Then flip Caddy’s reverse_proxy target and reload.

docker build -t my-app:new .
docker run -d --name my-app-new -p 3001:3000 --env-file .env my-app:new
curl -f http://localhost:3001/health || echo "new version unhealthy, stop here"
# if healthy: update the Caddyfile port to 3001, then
sudo systemctl reload caddy
docker stop my-app-old

This is a manual version of what a deploy pipeline automates later. Get it working by hand first so you understand every step before you script it.

What you get vs. what you don’t

You now have your app running with real HTTPS, behind a hardened server, restarting on its own if it crashes. What you still don’t have: tested backups, uptime alerts, and someone else to call at 3 a.m. Build those next, in that order.

Or, we do it for you

If you’d rather skip straight to a hardened, monitored, backed-up setup, get a free production audit first to see exactly where your current setup stands, or go straight to pricing.

FAQ

Do I need Kubernetes for this?

No. For a single small app, Kubernetes adds operational overhead most solo builders don’t need. Docker plus Caddy on one server is enough until you have a real reason to outgrow it.

What happens if the server itself goes down?

Nothing in this guide protects you from total server loss. That’s what off-server backups (see our backup tutorial) and monitoring are for, both worth setting up right after this.

Is this the same setup Stackbastion uses for customers?

The same building blocks: Docker, Caddy, hardened Ubuntu, plus the backup, monitoring, and on-call layer this guide doesn’t cover yet.