Deploy From Claude Code to Hosting You Control

You can take a site Claude Code built for you and put it on hosting you own — a VPS or a standard plan with SSH and Git — without ever touching a locked one-click platform. The short version: make a clean production build, push it to your server over SSH or Git, set your environment variables outside the code, and put a real certificate in front of it. That's the whole job.

Claude Code is good at writing the app. It is less opinionated about where the app should live, which is exactly the gap worth filling. Most tutorials nudge you toward the author's own platform because it's the easy sell. The trade-off they skip over: once your build, your domain, and your deploy pipeline all live inside one dashboard, leaving means rebuilding everything.

This walkthrough keeps the ownership with you. Everything below works on any Linux box you can SSH into, including a TPC Hosting VPS or a standard plan with shell access.

What "hosting you control" actually means here

It means you hold the SSH keys, the files sit on a server you can log into, and nothing about your deploy depends on one vendor's proprietary button. That's the test: if you can tar up your site and move it to a different host in an afternoon, you control it.

A locked platform hides the server from you. That feels nice until you need a cron job it doesn't offer, a second site on the same box, or a way out when pricing changes. Owner-controlled hosting gives you the raw ingredients — a shell, a web server, a filesystem — and asks a little more of you up front in exchange for never being stuck.

Two setups cover almost everyone reading this:

• Static or pre-built sites (a Next.js export, a Vite build, plain HTML Claude Code generated): upload the built files to a standard hosting plan with SSH, point the web root at them, done.
• Apps with a running process (Node, a database, API routes): a VPS, where you run the process yourself behind a reverse proxy.

If you're not sure which you have, look at what Claude Code produced. A dist or out folder of static files is the first case. A server.js or a framework that needs npm start in production is the second.

Step one: get a clean production build out of Claude Code

Ask Claude Code for the exact production build command and run it locally first, so you deploy a tested artifact instead of debugging on the server. The server is the worst place to discover a missing dependency.

For most JavaScript projects the pattern is the same. Install fresh, build, and check the output:

• npm ci — installs exactly what's in your lockfile, no surprises
• npm run build — produces the real output folder
• Serve that folder locally and click through it before you trust it

While you're here, ask Claude Code two specific questions: "What files does this project need at runtime versus build time?" and "List every environment variable this reads." The answers tell you what to upload and what to configure. If it hardcoded an API key or a database URL anywhere, have it move those to process.env reads now — before anything leaves your laptop.

Add a .gitignore that excludes node_modules, .env, and build caches. You'll push source and build on the server, or push the built files directly — either way, secrets and dependencies don't belong in your repo.

Step two: connect over SSH and move the files

Deploy by pushing your files over SSH with rsync for static sites, or by cloning your Git repo onto the server for apps you build there. Both start with a working SSH connection.

Generate a key if you don't have one and copy it to the server:

• ssh-keygen -t ed25519 -C "you@example.com"
• ssh-copy-id user@your-server-ip
• ssh user@your-server-ip to confirm you're in

For a static build, rsync is the cleanest tool — it only sends what changed:

rsync -avz --delete ./dist/ user@your-server-ip:/var/www/yoursite/

The --delete flag keeps the server matching your local folder, so old files don't linger. For an app, clone the repo on the server instead, then run npm ci && npm run build there so the build matches the server's own Node version:

• git clone your-repo-url /var/www/yoursite
• cd /var/www/yoursite && npm ci && npm run build

If you're on a TPC Hosting VPS, this is the same shell you'd use anywhere — no vendor wrapper between you and the box. If you get stuck on an SSH or permissions error at any hour, the AI on chat will work through it with you, and a real engineer follows up during business hours if it needs a human.

Step three: environment variables and the running process

Keep secrets in an environment file on the server, never in your repo, and load them when the process starts. This single habit is what separates a site you can safely share from one that leaks its database password on GitHub.

Create an .env file directly on the server, readable only by your user:

• nano /var/www/yoursite/.env — add your real keys here
• chmod 600 /var/www/yoursite/.env — lock down the permissions

For a Node app, don't run it with a bare node server.js that dies when you close the terminal. Use a process manager so it restarts on crash and on reboot:

• npm install -g pm2
• pm2 start npm --name yoursite -- start
• pm2 startup and pm2 save — survives a server reboot

Now put a reverse proxy in front of it so visitors hit port 80/443 and your app quietly listens on something like 3000. A minimal Nginx server block forwards traffic to your app and nothing else is exposed.

Step four: HTTPS, so the padlock is real

Put a free Let's Encrypt certificate in front of your site with Certbot, and let it renew itself — this takes about two minutes and never needs touching again. There's no reason to ship a site over plain HTTP in 2024.

On a VPS with Nginx:

• sudo apt install certbot python3-certbot-nginx
• sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
• Certbot edits your Nginx config, loads the certificate, and sets up auto-renewal via a systemd timer

Confirm the renewal works with sudo certbot renew --dry-run. If that passes, you're done — certificates roll over on their own every 90 days.

On a standard hosting plan, you usually don't touch Certbot at all; HTTPS is handled for you in the control panel. Point your domain's DNS at the server, wait for it to propagate, and enable the certificate from the panel. TPC's EU data centres mean your visitors' data stays in the EU end to end, which keeps the GDPR side of things simple.

Step five: keep the ability to leave

The whole point of owning your hosting is that you can walk away cleanly, so build that exit into your setup from day one. If leaving is hard, you don't really control the hosting — you're renting convenience.

A few habits make any move a non-event:

• Keep your source in Git, hosted somewhere independent of your host (GitHub, GitLab, your own).
• Write your deploy steps down in a DEPLOY.md — the exact commands, so a new server is a copy-paste job.
• Keep the .env keys documented (names, not values) so you know what to recreate.
• Back up any database with a scheduled pg_dump or mysqldump to a location off the server.

This is also where honest pricing and a real trial window matter. TPC gives you 30 days to back out and free migration to move an existing site in, so trying this setup costs you nothing but an afternoon. If it doesn't fit, you leave with everything — because it was all yours the whole time.

FAQ