Fly.io

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the deployment I actually need instead of Fly.io — and be honest about the verdict.

What you are paying for is **machines in several regions from one command**, private networking between them, and instances that suspend when idle. If you genuinely serve users on three continents and care about latency, that is hard to reproduce and worth paying for. If you have users everywhere but one database, the multi-region story is mostly an illusion anyway — your writes still cross the ocean. Most applications are one machine, and this is what that looks like done properly.

STACK
- One or two VPS instances at a provider you like
- Docker or Podman for the application and its services
- Caddy in front for TLS and routing
- Bash and systemd for the deploy. No orchestration platform for one machine

THE HONEST ARCHITECTURE QUESTION
- Multi-region reads are useful. Multi-region writes are a distributed database problem, and adding regions without solving it just adds latency and failure modes
- So: one primary region with the database, and read replicas elsewhere only if you have measured that reads are the problem. Route writes to the primary and accept the replication lag deliberately
- Put a CDN in front of anything static. That solves most of what "close to your users" actually means, for a fraction of the effort
- Write this decision down before you start, because "we should be multi-region" is the most expensive unexamined assumption in hosting

THE SHAPE
- /srv/<app>/releases/<timestamp> per deploy, /srv/<app>/current a symlink
- /srv/<app>/shared holds .env, uploads and the database, symlinked into each release. Nothing that must survive a deploy lives inside one
- Deploy is: fetch, build, migrate, switch the symlink, restart, health check. A failure at any step leaves the old release serving
- Rollback moves the symlink back. One command, tested before it is needed

WHAT REPLACES EACH FEATURE
- One command to deploy becomes a shell script that refuses on a dirty tree and rolls back on a failed health check
- Machines that suspend when idle become one small always-on instance, which costs a few euros and has no cold start at all — usually the better trade
- Private networking between regions becomes a WireGuard mesh if you truly need it, and nothing if you do not
- Automatic TLS becomes Caddy, which is two lines
- Zero-downtime deploys become a second process on a second port with Caddy switching once the new one passes its health check. Twenty lines, and worth it
- Volumes become a directory, backed up nightly, off the machine

DATABASE AND STATE
- Migrations run before the symlink switch, each once, in order
- Backwards-compatible across a deploy: add a column, deploy, use it, remove the old one later. Never in the same deploy
- Continuous replication of the database to object storage, which gives you point-in-time restore
- A restore rehearsed onto a clean machine, with the time it took written down. That is the entire disaster-recovery story

THE OPERATIONAL FLOOR
- Log rotation before the disk fills, a swap file so a memory spike degrades instead of killing the process, unattended security updates, a firewall allowing only what is needed, ssh on keys
- Certificate renewal monitored, disk alerted at 80 per cent
- An uptime check from somewhere that is not this machine — the one thing here you should not self-host
- Everything on this list fails at once when the disk is full

WHAT YOU ARE SIGNING UP FOR
- You are the operator now: updates, disk, backups, and the person who is called. Write that in the README alongside what it costs and what it replaces

WHAT MATTERS MOST
The failed deploy, the rollback and the tested restore — and deciding honestly whether you need more than one region. Break the build deliberately and confirm the site stayed up, then restore a backup onto a clean machine and time it.