How to deploy any app 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 a fully managed platform gives it to you without provisioning, securing or patching anything.

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.

Getting the workflow with zero setup

With a managed PaaS the whole pipeline is already running on our cloud — you just point it at a repo. The shape of getting started:

1. 1Sign up free. The Free plan runs one app on 512MB / 0.5 vCPU with automatic HTTPS and preview deploys — no credit card.
2. 2Connect your Git repo. Point DeployCloud at a GitHub repository and choose the branch to track.
3. 3Push. DeployCloud builds the image, runs release tasks and starts a health-checked container on our infrastructure.
4. 4Go live on HTTPS. Every app gets a URL with an automatic certificate; add a custom domain and it's provisioned for you.

From then on, deploying is just git push. You get automatic HTTPS, zero-downtime releases and one-click rollback — with nothing to provision, secure or maintain.

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 assemble the pipeline yourself, DeployCloud gives you the full git-push-to-live-HTTPS workflow, fully managed, out of the box.