How to deploy any app to your own VPS with git push

For years, 'deploying' meant SSHing into a box, pulling code, installing dependencies, running a build, restarting a process and hoping nothing broke. Heroku replaced all of that with one command — git push — and it felt like magic. The magic is reproducible, and you can have it on your own VPS.

What actually happens on a git push deploy

Under the hood, a git-push PaaS turns a single git push into a pipeline. Each step is automatic:

1. 1Receive the push. The platform receives your new commit on the tracked branch.
2. 2Build an image. It builds a container image — from your Dockerfile if you have one, or by auto-detecting the stack with a builder like Nixpacks.
3. 3Run release tasks. Any one-off release step (like database migrations) runs before the new version takes traffic.
4. 4Start and health-check. The new container starts and is checked on a health endpoint before it's allowed to serve.
5. 5Switch traffic. A reverse proxy cuts traffic over to the new version with zero downtime, and the old one is retired.
6. 6Keep the old release. The previous image is kept so you can roll back instantly if needed.

Any language, thanks to build detection

The reason this works for 'any app' is the build step. You have two clean options:

• Bring a Dockerfile. If your repo has one, the platform builds exactly what you defined — full control, any stack.
• Let Nixpacks detect it. With no Dockerfile, a builder like Nixpacks inspects your repo and produces an image automatically for Node, Python, Go, Ruby, PHP, Rust, Java and more.

Either way, the output is a standard container image — which is what makes the rest of the pipeline (health checks, rollback, scaling) uniform regardless of language.

The Procfile: declaring your processes

Most real apps are more than a web server. A Procfile — borrowed straight from Heroku — lets you declare each process type:

web: node server.js
worker: node worker.js
release: npx prisma migrate deploy

web takes HTTP traffic, worker runs your background queue, and release runs once per deploy before traffic switches — the ideal place for migrations. Scale web and worker independently as load grows.

Setting it up on your own VPS

The fastest path is a single-server PaaS that packages the whole pipeline. The shape of it:

1. 1Get a Linux VPS with Docker — any mainstream provider works.
2. 2Install the platform. Tools like DeployCloud install as a docker-compose stack in a few minutes.
3. 3Point DNS at the box — an A record for your domain plus a wildcard for per-app subdomains.
4. 4Connect your repo and push. The platform builds, releases behind a reverse proxy, and issues a Let's Encrypt certificate automatically.

From then on, deploying is just git push. You get automatic HTTPS, zero-downtime releases and one-click rollback without assembling any of it yourself.

Why not just a deploy script?

You can hand-roll this with a bash script and a systemd unit — plenty of people do. The reason a PaaS wins is everything around the happy path: health checks that stop a broken build from serving, instant rollback when one slips through, preview environments per branch, and a log and metrics view you didn't have to build. That's the difference between a deploy that works on a good day and one you trust at 2am.

If you'd rather not build the pipeline yourself, DeployCloud gives you the full git-push-to-live-HTTPS workflow on your own server out of the box.