SMF·HEROKU-BASIC
Can a prompt replace Heroku?
Hosting & deployment — application hosting and backend platforms
Exhibit tracking slip
Verdict
Recreating Heroku's signature "git push to deploy" workflow on a single VPS — build a Dockerfile from the pushed repo, run it as a container, and route it through a reverse proxy with automatic TLS — is a real, working platform for a personal project, and doable in one sitting with Coolify or a similar tool, or a bit more hand-rolled with Caddy. What it can't match is Heroku's managed add-on ecosystem and multi-region reliability behind that one command.
Exhibit A — The prompt
Received on31.07.2026Build a personal single-server PaaS: git push to deploy, Docker builds, and automatic HTTPS routing. Stack: a bare Git server (or Gitea) with a post-receive hook, Docker, Caddy as the reverse proxy, PostgreSQL for deployment metadata.
Core loop: the operator pushes a repository to a Git remote on their own VPS. A post-receive hook builds a Docker image from the repo's Dockerfile, stops the previous container for that app if one exists, and starts the new one, then updates Caddy's routing config so `<app>.yourdomain.com` proxies to the new container with automatic TLS certificate issuance. Keep a small metadata table of apps, their subdomains, environment variables (encrypted at rest), and deployment history, with a simple CLI or web view to see logs and roll back to the previous image if the new one crashes on startup.
This needs a VPS you administer yourself (a few dollars a month from any provider) and a domain with DNS pointed at it — Caddy handles certificate issuance automatically once DNS resolves. No third-party account beyond the VPS and domain registrar.
Do not build: multi-region deployment, autoscaling, or a managed add-on marketplace — provisioning a database means running it yourself on the same box (or a second one) and wiring the connection string in by hand. State plainly in the README that this is one server: if it goes down, every app on it goes down with it, and there's no automatic failover.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 a managed add-on marketplace (databases, caching, monitoring) provisioned with one click
- B.2 multi-region deployment and automatic failover if one server goes down
- B.3 autoscaling under traffic spikes
- B.4 Heroku's own operations team handling patching, isolation, and incident response
- B.5 a free tier to experiment on before committing to your own always-on server
Prior art
Exhibit C — Why people still pay: infrastructure scale, operations, and reliability
People pay for Heroku because a single self-hosted server is exactly that — one server, one failure domain, no operations team behind it. The recurring cost buys a managed add-on ecosystem and infrastructure that fails over across regions, not the git-push deploy mechanic itself, which is genuinely replicable.
Questions
Can I import my existing Heroku apps?
If your app already has a Dockerfile (or you add one — Heroku's buildpacks handle this automatically, this build doesn't), deploying it is just pointing your git remote at the new server. Heroku add-ons (databases, Redis, etc.) need to be reprovisioned yourself, since there's no equivalent marketplace here.
Will it work on my phone?
The web dashboard for viewing logs and app status works from a phone browser. Actually pushing code to deploy needs a real development environment, same as it would with Heroku.
What does it cost to run?
A VPS capable of running a few small apps runs $10–20 a month depending on provider and size — often less than a single Heroku dyno, though you're trading the price difference for doing your own operations.
What's the one thing that doesn't survive the rebuild?
Failover. Heroku's infrastructure spans multiple availability zones so one server dying doesn't take your app down; here, it's one VPS, and if that machine has a hardware failure or the provider has an outage, every app on it is down until you personally fix it.
Related tools
Receipt