Connect a GitHub, GitLab or Bitbucket repository, pick a branch, and every push becomes a built, health checked release on your own server. The old release stays on disk, so a bad deploy is one click away from being undone.
# free plan · no credit card required
Deploys to Hetzner, DigitalOcean, AWS, Vultr, Linode, OVHcloud and any custom VPS.
To deploy from Git, connect your repository to a deployment tool, nominate a branch, and let a webhook trigger a build on every push. The tool checks out the exact commit into a new release directory, installs dependencies, builds assets, runs migrations, then switches a symlink so traffic moves to the new release only after it passes a health check. That is the difference between a Git deployment and running git pull on the server: a pull edits the directory visitors are already reading from, so a half finished install is served live and there is nothing to roll back to. DeployManage does the checkout, the build, the atomic switch and the rollback for GitHub, GitLab and Bitbucket repositories, on servers you own.
Last updated August 2026
Authorize the provider once and pick a repository from the list. Private repositories work through a per server deploy key with read only access to that one repo, which is the access model GitHub recommends over reusing a personal account token across machines.
Point production at main and staging at develop, on the same server or different ones. The branch is a setting, not a script edit, so promoting a release never means editing YAML in a repository at 6pm.
A webhook on the nominated branch starts a deploy the moment code lands. If production needs a human in the loop, leave the trigger manual and let staging auto deploy. Both models are one toggle, not two different pipelines.
Dependency installs and asset compilation happen in the new release directory while the current release keeps serving traffic. If composer install or npm ci fails, the deploy stops there and the live site never sees the broken build.
Each deploy gets its own timestamped directory and a symlink flip promotes it. The switch is a single filesystem operation, so no request ever sees a half copied application. Older releases stay on disk for instant rollback.
After the switch, the release is checked over HTTP. A failing check reverts the symlink to the last known good release automatically, which is the part a hand rolled git pull deploy almost never has.
Authorize GitHub, GitLab or Bitbucket. DeployManage reads your repository list and generates a deploy key for the server, so a private repository never needs your personal credentials sitting on a box.
Create a server on Hetzner, DigitalOcean, AWS, Vultr, Linode or OVHcloud with your provider API key, or attach a VPS you already run. The server gets a hardened base install, a firewall and SSL before the first deploy.
Choose the branch to track and confirm the build commands for your stack. Defaults cover the common cases, and anything unusual goes in a deploy script that runs inside the new release directory rather than over the live one.
The webhook fires, the commit is built in a fresh directory, the health check runs and the symlink flips. The deploy log records the commit SHA, so you always know exactly what is running in production.
There are four common ways to get a commit from a repository onto a server you own. They differ mostly in what happens when something fails halfway. Here is what each is genuinely good at, including where DeployManage is the wrong choice.
swipe to see all columns →
| What you need | DeployManage | git pull on the server | GitHub Actions plus SSH | DeployHQ |
|---|---|---|---|---|
| Primary job | Provision the server and ship Git releases to it | Update the working copy in place | Run any CI workflow, deployment is whatever you script | Deploy code from a repository to servers, FTP or S3 |
| Setup before the first deploy | Authorize the provider, pick a repo and branch | SSH in, clone, add a deploy key, write a script | Write a workflow file, add SSH keys as repository secrets | Connect the repo, add server credentials, set the path |
| What visitors see during a deploy | Nothing: the symlink flips after the health check | A partially updated app while files are written | Depends entirely on the script you wrote | Depends on the deployment mode you configure |
| Rollback | Automatic on a failed health check, previous release kept on disk | Manual: check out the old SHA and hope migrations reverse | Whatever you built yourself | Yes, redeploy a previous revision |
| Builds Composer or npm before going live | Yes, inside the new release directory | Usually run against the live directory | Yes, on the runner, then you copy the artifact across | Yes, build pipelines are supported |
| Also provisions and manages the server | Yes: firewall, SSL, databases, queues, cron | No | No | No, it deploys to a server you already run |
| Published pricing | Free to start | Free, you pay in maintenance | 2,000 free minutes a month on GitHub Free, then per minute billing | Free tier, then 9 to 99 euro a month by plan |
| Wrong choice when | You want a container orchestrator or a managed PaaS that hides the server | The site earns money and a bad deploy costs more than an afternoon of setup | You want deployment to be configuration rather than a workflow you maintain | You also need the server itself provisioned and managed |
Thirty repositories across a handful of servers, each with its own branch policy. Deploying from Git means the release history matches the commit history, so when a client asks what changed on Tuesday you answer from the deploy log instead of guessing.
The script worked when one person used it. Now it has grown flags, a maintenance mode toggle and a comment nobody understands. Moving the same steps into a Git deployment removes the tribal knowledge and gives everyone the same rollback.
One founder, three production apps, no ops help. Push to deploy plus an automatic health check means a broken build is caught by the machine at 2am rather than by a customer email at 9am.
A long lived Laravel, Rails or Node application with a background worker, a scheduled job and a database that has to stay where it is. Git deployment onto your own server keeps the architecture and removes the manual steps.
Most projects start the same way. You SSH into the server, run git pull, run composer install or npm ci, restart the process, and call it a deploy. It works right up until it does not, and the failure mode is always the same: the pull rewrites files inside the directory nginx is already serving.
During those few seconds the application is a mixture of two versions. A request that loads the new template but the old controller throws. A request that arrives after a migration starts but before the code that uses the new column lands hits an error. If composer install fails on a network blip, the live site is now running new code against old dependencies, and there is no previous release directory to fall back to because you overwrote it.
Deploying from Git properly means the commit is turned into a release somewhere else first, and only becomes live once it is complete. That single design decision is what makes rollback possible at all.
A release model deploy runs in a fixed order, and each stage can fail safely because the current release is still serving traffic:
Steps two through five all happen while the old version is still answering requests. That is the entire point, and it is why the ordering is not negotiable.
The wrong way to give a server access to a private repository is to put a personal access token or a developer's SSH key on it. That key can usually read every repository the person can, and when they leave the company you have to remember which servers hold it.
The right way is a deploy key: an SSH key pair generated for one server, added to one repository, with read only access. If the server is compromised, the blast radius is one repository's source code, and revoking it is a single click in the repository settings. GitHub, GitLab and Bitbucket all support this model, and DeployManage generates the key per server so you never paste a private key into a form.
The second half of this is the environment file. Secrets should never be in the repository, which means they cannot arrive with the checkout. Keep them in a shared path on the server that gets symlinked into each new release, so a deploy never overwrites production credentials with whatever was in the last committed example file.
Once an app runs behind a load balancer, deploying from Git gets a new constraint: the servers must not switch at wildly different times, or a user's session bounces between two versions of the application. The practical approach is to build every server's release directory first, then flip the symlinks in quick succession, then reload the application servers.
The alternative is a rolling deploy, where servers are drained from the load balancer one at a time, updated and returned. That gives you a smaller failure radius at the cost of running two versions concurrently for the length of the rollout, which your database schema has to tolerate. The tradeoffs are covered in more detail in our comparison of blue green and rolling deployment.
Whichever you pick, the rule that does not change is that the schema must work with both the old and the new code for the duration of the rollout. Adding a column is safe. Renaming one in a single release is not.
GitHub Actions is genuinely good at the CI half of the job: run the test suite on every pull request, build an artifact, publish a package. Deployment is where it gets expensive in maintenance, because Actions has no opinion about releases. Everything about atomic switching, health checks and rollback is code you write and then own forever, usually as a YAML file plus an SSH action plus a shell script that lives in the repository.
There is a cost dimension too. GitHub's published limits give GitHub Free 2,000 Actions minutes a month and GitHub Pro and Team 3,000, with usage on public repositories and self hosted runners free. Beyond the quota, standard Linux runners bill per minute. A deploy that builds a large frontend several times a day adds up faster than teams expect.
The pragmatic split most teams land on: let Actions run the tests, and let a deployment tool own the release. If you want the full comparison, we wrote up deploying to a server with GitHub Actions, including the SSH setup, the self hosted runner option and the real limits.
If the tool you are weighing this against is DeployHQ specifically, the DeployHQ alternative comparison goes through its pricing, its Subversion and SFTP support, and the server management gap it leaves open.
Connect the repository to a deployment tool, add a deploy key so the server can read the repo, and configure a webhook on the branch you want to track. On every push the tool checks the commit out into a new release directory, installs dependencies, builds assets, then switches a symlink to make it live. DeployManage does all four steps for you.
Yes. Deploying directly from a Git repository is the standard model: the server, or a service acting on its behalf, checks out a specific commit and turns it into a release. What matters is that the checkout goes into a fresh directory rather than over the running application, so a failed install never reaches visitors.
Git based deployment means the repository is the source of truth for what runs in production. A push to a nominated branch triggers a deploy of that exact commit, so the deployed version is always identifiable by SHA. It removes manual file uploads and makes the release history match the commit history.
Not for anything that earns money. git pull rewrites files inside the directory that is currently serving traffic, so requests during the pull can hit a mix of old and new code. It also leaves nothing to roll back to, because the previous version has been overwritten. Use a release directory and a symlink switch instead.
Provision the VPS with a web server, your language runtime and a firewall, add a read only deploy key for the repository, then point a deployment tool at the branch. The tool clones the commit into a release directory on the VPS, builds it, and flips a symlink once a health check passes. No FTP and no manual file copying.
Use GitHub Actions for continuous integration: tests, linting and build artifacts. Use a deployment tool for the release itself, because Actions gives you no atomic switch, no health check and no rollback unless you write and maintain them. Many teams run both, with Actions gating the merge and the deploy tool shipping it.
Generate an SSH deploy key on the server and add the public half to that single repository with read only access. Never reuse a developer's personal key or a broad personal access token, because those can read every repository the account can. Revoking a deploy key affects one repo and one server.
Yes, and you should. Point production at main and staging at a development branch, each with its own server or site. Because the branch is a setting rather than a hardcoded value in a script, promoting or freezing a release does not require editing and committing a pipeline file.
Build the new release directory on every server first, then switch the symlinks in quick succession and reload each application server. Doing the slow work everywhere before any server goes live keeps the versions in step. If you drain servers one at a time instead, your database schema must support both versions at once.
It does when the deploy writes over the live directory, which is what git pull does. It does not when each commit is built in its own release directory and promoted with an atomic symlink switch, because the old version serves every request until the moment the new one is complete and healthy.
A deploy key is an SSH key pair granted access to a single Git repository, usually read only, and installed on one server. It is the recommended way to let a machine pull private source code, because it limits access to that one repository instead of everything the key owner can see.
Yes. GitLab and Bitbucket both support deploy keys and webhooks, so the deployment model is identical: a push to the tracked branch triggers a checkout of that commit into a new release. DeployManage connects to GitHub, GitLab and Bitbucket, and a project can move between them without changing how it deploys.
Connect a GitHub, GitLab or Bitbucket repository, provision a server on the cloud you already use, and every push ships a health checked release with a rollback waiting behind it.
# free plan · no credit card required