Heroku

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 paying for Heroku: git push, build, run, roll back, on a machine I rent for a fraction of it.

Read this first: what you are giving up is real. Buildpacks that detect and build almost anything, an add-on that is one command away, and zero-downtime releases with no configuration. What you get is a machine with ten times the memory for a tenth of the price, and no surprise bill. For one application on one server, that trade is usually right.

STACK
- One VPS with Debian or Ubuntu
- Docker or Podman for the application and its services, or plain systemd if the application is a single Node process
- Caddy in front for TLS and routing
- Bash for the deploy, systemd timers for the schedule. No orchestration platform — a cluster manager for one server is a second system to operate

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

WHAT REPLACES EACH THING YOU ARE LOSING
- Buildpacks become a Dockerfile or a twenty-line build script. Less magic, and it never surprises you at two in the morning
- Add-ons become containers: Postgres, Redis, whatever else, each with a named volume, a memory limit, a restart policy and a health check. Bound to localhost, never to a public interface — an exposed database port is found by a scanner within the hour
- Zero-downtime releases become a second process on a second port with Caddy switching between them once the new one answers its health check. Twenty lines of configuration, and worth it
- The dashboard becomes systemd, journalctl and a status script that prints what is running, what version, and how long it has been up
- `heroku run` becomes ssh and a script that runs a command inside the current release with the right environment
- Review apps become a script that deploys a branch to a subdomain on the same box, with its own database, and destroys it when the branch goes

CONFIGURATION AND SECRETS
- One .env in shared, root-owned, mode 600, never in the repository
- A script to set and read values, so nobody edits it with a text editor and leaves a stray quote
- Every secret is rotatable and you have rotated one at least once as a rehearsal

DATABASE
- Migrations run before the symlink switch, each once, in order, inside a transaction where the engine allows it
- A backwards-compatible migration policy: the old release must keep working against the new schema for the length of a deploy. Add a column, deploy, use it, then remove the old one in a later deploy — never in the same one
- Nightly backup that dumps, compresses, uploads off the machine, and prunes old copies
- A restore script, and a restore actually performed once onto a fresh machine with the time it took written down. An untested backup is not a backup

THE THINGS PEOPLE FORGET UNTIL IT HURTS
- Log rotation, configured before the disk fills
- A swap file, so a memory spike degrades instead of killing the process
- Unattended security updates, with reboots scheduled rather than automatic
- A firewall allowing only what is needed, and ssh on keys with passwords disabled
- Fail2ban or its equivalent
- Certificate renewal, which Caddy does, and a monitor that tells you if it ever stops
- An uptime check from somewhere that is not this machine, which is the one thing here you should not self-host
- A disk-space alert at 80%, because everything on this list fails at once when the disk is full

WHAT YOU ARE SIGNING UP FOR
- Write it down honestly in the README: you are now the operator. Security updates, disk, backups, and being the one who is called. A restart is a second of downtime and for almost everything that is fine
- Also write down what it costs and what it replaces, because that number is why this is worth doing

WHAT MATTERS MOST
The failed deploy, the rollback and the tested restore. Break the build deliberately and confirm the site stayed up; roll back and time it; restore the backup onto a clean machine and time that too. Everything else is convenience — those three are what let you sleep.

Give me the deploy script, the rollback script, the zero-downtime Caddy configuration, the systemd units, the backup and restore scripts, the firewall rules, and a README that reads as a runbook.