If you’ve ever used Heroku, Render, or Railway, you understand the appeal: push code, get a URL, done. The problem is the pricing. As soon as you move beyond toy projects, per-dyno and per-seat costs stack up fast. And you’re entirely at the mercy of the platform — if they change pricing or go down, you have no lever to pull.
There’s a better way. Here’s exactly how automatic zero-downtime deployments work — and what changes for you when your infrastructure is managed properly.
The Deployment Trigger
The moment you push to your main branch, a webhook fires to the deployment platform. It receives the push event, pulls the latest commit, and starts a build. You don’t initiate this manually. You don’t SSH into anything. You push; the rest happens automatically.
Auto-Detecting Your Stack
Most apps don’t need a Dockerfile at all. The platform uses Nixpacks to auto-detect your stack from the repo. Push a Next.js app — it detects Node and builds it. Push a Django project — it detects Python and installs dependencies. FastAPI, Rails, Laravel, Elixir — Nixpacks handles all of them.
A Dockerfile is only written when the stack is genuinely unusual: monorepos, multi-service apps without a standard layout, or apps with custom build steps that can’t be inferred. That’s a one-time setup at onboarding. You never touch it again.
The Zero-Downtime Swap
This is the part most DIY setups get wrong. Here’s what actually happens:
- A new Docker image is built from the latest commit
- The new container starts and passes a health check
- Traffic is cut over from the old container to the new one — atomically, at the load balancer level
- The old container is stopped and removed
No restart window. No 502 errors during deploys. If the build fails or the health check doesn’t pass, the old container keeps serving traffic unchanged. The failed deploy never touches your users.
Isolated Per-Client Infrastructure
Each client runs in their own Docker Compose project. One client, one project, one set of volumes, one database container. There is no shared database server where your data sits next to someone else’s.
This isolation matters for a few reasons:
- A traffic spike on one app doesn’t affect yours
- Backups, rollbacks, and restores are scoped to your project only
- Credentials and environment variables are stored per-project in an encrypted panel — never in Git
What You See From Your End
You push to main. A minute or two later, the new version is live. If something goes wrong, rollback to the previous image is one click.
You don’t run docker build. You don’t manage certificates. You don’t write Nginx configs. That all happens on the infrastructure side.
Why Not Just Use Render or Railway?
There’s nothing wrong with managed PaaS if the pricing works for you. But consider:
- Render starts at $7/month per service and charges extra for databases
- Railway is usage-based and can surprise you at month-end
- Heroku Basic dynos sleep after 30 minutes of inactivity
On our infrastructure, the cost is a fixed monthly fee. You can run five services for the same price as one on Render. Predictable, no sleeping instances, no per-seat charges.
The Open Source Foundation
The deployment tooling we use is MIT-licensed. If it stopped being maintained tomorrow, nothing breaks — the Docker containers and Traefik config keep running. There’s no vendor lock-in at the platform level.
That’s not a hypothetical concern. Heroku removed its free tier in 2022 with 30 days’ notice. Platform decisions can happen quickly. Running on open-source infrastructure is insurance against that.
If you want to see how your app would fit into this setup, get in touch — we can usually tell you within a conversation whether auto-detection will handle it or whether a custom config is needed.