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

You can get the whole "push to deploy" experience on a server you own, without a platform in the middle. Git-push deploy means you run git push, and seconds later your new code is built and live on your own box. No proprietary pipeline, no build-minute meter, no platform outage that becomes your outage. It is the shipping experience people love about managed platforms, running on infrastructure you fully control. And it is far simpler to set up than most engineers expect.

This is how I ship every company in my portfolio. One push, my own server, no vendor holding the keys. Here is the pattern and how to build it.

What git-push deploy actually is

The idea is that your server holds a git repository, and a hook fires whenever you push to it. That hook checks out the new code, builds it, and restarts your application process. Your local git push becomes the entire deploy. There is no external service involved: the trigger, the build, and the restart all happen on the box you own.

This is the same mental model as the managed platforms that made push-to-deploy popular, minus the platform. You keep the ergonomics and drop the dependency. The runtime is yours, the deploy logic is yours, and it runs anywhere Linux runs, which means moving to a different box is copying a few files, not migrating a pipeline.

How to build it, step by step

Start with an owned box. A plain VPS with a firewall, key-based SSH, and your app's runtime installed. This is the foundation I described in what a deploy you actually control looks like. Nothing exotic, just standard Linux under your control.

Set up a bare repo and a hook. On the server, create a bare git repository and add a post-receive hook. That hook is a short shell script. When you push, it checks out the latest code into your app directory, runs your build, and restarts the process. This is the entire engine, and it is a page of shell you can read top to bottom.

Add your server as a git remote. Locally, add the server as a remote over SSH. Now git push production main sends your code straight to the box, the hook runs, and the app updates. That is the whole loop.

Make rollback one command. Keep the previous release around so you can repoint to it instantly if a deploy goes wrong. A deploy you cannot cleanly undo is not finished. This is what turns push-to-deploy from a party trick into something you trust on a launch day.

Why do this instead of a managed pipeline

Control and portability, mostly. A managed pipeline is convenient, but it concentrates risk: your ability to ship depends on the platform's uptime, pricing, and proprietary config. When it has a bad day, you have no move. The git-push setup answers only to you. It ships during their outages, it costs nothing per deploy, and it moves to any box in minutes.

There is also the lock-in angle. Once your deploys are expressed in a platform's proprietary format, leaving means rebuilding your release process from scratch. The git-push pattern is just git and shell, which run everywhere, so your switching cost stays near zero. I made the fuller case for owning this whole layer in how to own your deploy pipeline end to end.

Keep it simple, then grow

Resist the urge to overbuild this. You do not need a heavyweight CI system or an orchestration platform to ship one app. The bare-repo-plus-hook pattern runs a serious application for a long time before it needs anything more. Add tests in the hook, a staging remote, or build caching when a real problem asks for them, not preemptively. The strength of this setup is that you can understand all of it, which means you can fix all of it.

I run this exact pattern across the portfolio on HostSSH. Every company ships with a push to a box I own, rolls back with one command, and depends on no external pipeline to reach production. It took an afternoon to set up the first time and has never held me hostage since.

Push-to-deploy was always the good part of managed platforms. The dependency was the bad part. Git-push deploy on your own server gives you the good part and keeps the machine yours.