Last updated on 6th May 2026

Migrating to DeployHQ

DeployHQ is built to be a drop-in replacement for the most common ways teams ship code today: hand-written deploy scripts (Capistrano, Deployer, Mina), CI-runner deployments (GitHub Actions, GitLab CI, CircleCI, Jenkins), and competitor platforms (DeployBot, Buddy, Octopus Deploy). The mechanics change. The contract — Git in, atomic releases out, lifecycle hooks in between — does not.

These guides walk you through what each migration looks like in practice: what maps directly, what you have to translate, and what DeployHQ adds that your previous tool did not.

What every migration looks like

Whatever you are coming from, the same three pieces move across:

  1. Your repository. DeployHQ checks out code on our build infrastructure. Point us at the same repo URL you use today (Git, SVN, or Mercurial). Read-only deploy keys are generated automatically. No git binary needed on the target server.
  2. Your servers and stages. Each environment in your existing tool — production, staging, qa — becomes a DeployHQ environment, with the same SSH targets, deploy paths, and shared files/directories. Existing servers are reused; nothing is provisioned unless you explicitly ask for it.
  3. Your lifecycle hooks. Anything that ran before, during, or after a deploy in your old tool — db:migrate, assets:precompile, service restarts, cache warmups — becomes an SSH command tied to the equivalent DeployHQ stage (before upload, after upload, before symlink, after deploy).

For most projects this is a half-day of work. Multi-stage Rails or Laravel apps with background workers, asset pipelines, and database migrations are typically a full day.

Two ways to migrate

Option Best for What you do
Self-serve Teams comfortable with their existing deploy config Follow the relevant guide below. Connect repo, recreate environments, translate hooks. Deploy to a staging environment first, verify, cut production over.
Concierge migration Production systems, multi-server setups, anyone who wants a second pair of eyes Available on Pro and above. Send us your existing deploy config (deploy.rb, deploy.php, .github/workflows/deploy.yml, etc.) and we will rebuild the project with you on a screenshare.

Either way, your existing setup keeps running until you are confident. There is no flag day — DeployHQ deploys to your servers in parallel with whatever you are using today, so you can compare outputs before cutting over.

What DeployHQ adds

The features below are common across every migration path — these are what teams typically gain regardless of where they are coming from:

  • A web UI and audit log. Every deploy is recorded with who triggered it, from which branch, at which commit, and what each step output.
  • One-click rollback. DeployHQ keeps the last N releases on the server (configurable per environment). Rollback flips the symlink. See Rolling back a deployment.
  • Build pipelines. Run bundle install, npm ci, composer install, yarn build, etc. once on our build infrastructure — not on every target server.
  • Per-environment permissions. Grant deploy-to-staging without granting deploy-to-production. Junior engineers can ship without root access.
  • REST and GraphQL API plus a CLI. Deploy from a browser, your terminal, or a CI step. Same atomic release semantics either way.
  • AI deploy error explanation. When a deploy fails, the failed step is summarised in plain English with a likely fix.
  • Hybrid setups welcome. If you want to keep your existing CI for testing and only move the deployment step, the API and CLI make that trivial. You do not have to migrate everything at once.

Available migration guides

Still evaluating?

If you are deciding between DeployHQ and another tool rather than committing to a migration, start with the side-by-side feature comparisons. Each one covers pricing, feature parity, ideal use cases, and where the other tool is genuinely the better fit — we link to the alternative when it is.

Script-based deploy tools (a deploy.rb, deploy.php, or equivalent):

CI runners and deployment automation:

Docker and self-hosted PaaS:

Server provisioning and hosting panels:

The full index is at deployhq.com/compare.

When you are ready to migrate, find your tool in the list above and follow the guide. If your tool is not listed, email support@deployhq.com — we are actively expanding migration coverage and can prioritise based on demand.