Set Up Git Push-to-Deploy on Your Own Server

From the webhook to the deployed container: how push-to-deploy workflows operate, and how to have Heroku's workflow on your own VPS.

The workflow that should be replicated
The legacy that Heroku left behind is a workflow: git push equals deploy. No babysitting of build servers, no shuttling of artifacts, no SSH into any server. Branches equal environments, pushes equal triggers, and the log stream is what tells you the story. Every component in that workflow can be easily replicated on a $5 VPS.

Anatomy Pipeline
For those cases where push-to-deploy is possible, here’s what’s under the hood:

1. Push: The Git service sends an HTTP POST webhook containing commit data

2. Validate and filter: The platform validates the webhook and ensures that the branch has been associated with one of our services

3. Pull and build: The target server pulls down and builds the exact commit in question

4. Inject and roll: The environment variables are injected into the new container, and a rolling update takes place

5. Notify: The build and run-time logs get streamed into the dashboard, along with success or failure notifications

DIY versus platform, honestly
You can hand-roll this: a bare repo with a post-receive hook, or a GitHub Action that SSHes in and runs docker compose up. It genuinely works, and for one project it is a fine weekend of plumbing. The gaps appear with use: no build logs anyone can see, no locking (two rapid pushes race), secrets scattered in .env files, no health-gated rollout or automatic rollback, and CI now holds SSH keys to production.

A deployment platform is that plumbing, productized: Peon registers webhooks automatically when you connect a repo, serialises builds per service, injects encrypted variables, rolls out behind health checks and keeps rollback one click away.

Configuring it in Peon
Authenticate with GitHub or GitLab once as a Git source (as an OAuth application or Personal Access Token)

Generate a service out of a repository; choose the branch (main is used for production) and build strategy (Dockerfile or automatic detection)

The webhook gets configured automatically; push to see the live build logs streaming

Generate another service out of the same repository on a different branch (staging), same pipeline, second environment and single server

Branch strategy & CI coexistence
“Don’t make it interesting” - primary branch deploys into production, staging into staging, and feature branches do not deploy anywhere until they get merged (or preview services if review apps prove themselves useful for you). Your CI retains its functions, but tests and checks are now performed on pull requests as always; the trigger to deploy is just the merge event.