Migrating from Capistrano to DeployHQ
A drop-in successor for any-VCS, any-SSH deployments — with a UI, audit log, and atomic releases out of the box.
Capistrano was the standard for SSH-based deployments for the better part of a decade. It still works. But the project has slowed: between June 2024 and December 2025 it shipped a single feature release (v3.19.0), and v3.20.0 in December 2025 was a housekeeping release that dropped support for old Ruby versions without adding new functionality. If your deploy.rb works today, it will keep working — but you are no longer riding a maintained product roadmap.
DeployHQ keeps the parts of Capistrano you actually relied on (any VCS, any SSH target, atomic symlinked releases, before/after hooks) and adds the parts you have always had to bolt on yourself: a web UI, an audit log of every deploy, automatic rollback, build pipelines, and — if you want it — a managed Ubuntu server provisioned in the same dashboard.
For a side-by-side feature comparison, see DeployHQ vs Capistrano. If you are weighing your options across Ruby deploy tools, the same migration shape applies to Mina — see Migrating from Mina to DeployHQ. If you have already moved past Capistrano to Kamal and are now reconsidering, see Migrating from Kamal to DeployHQ. If you work in PHP, the equivalent guide is Migrating from Deployer to DeployHQ. If your deploys currently run inside a CI pipeline rather than from cap, see Migrating from GitHub Actions to DeployHQ for the hybrid pattern (CI in Actions, deploy in DeployHQ).
The case for migrating now
Capistrano's release history tells a clear story:
| Version | Released | What changed |
|---|---|---|
| v3.19.0 | 2024-06-24 | Added REVISION_TIME |
| v3.19.1 | 2024-07-02 | Pager bug fix for v3.19.0 |
| v3.19.2 | 2024-11-07 | One-line constant fix |
| v3.20.0 | 2025-12-13 | Dropped Ruby 2.0–2.4 support. No new features. |
That is one year and six months between the last meaningful feature release (v3.19.0, June 2024) and today. The maintainers are not absent — they are still merging PRs and keeping the gem compatible with newer Ruby versions — but the project is in maintenance mode, not active development.
If you have ever wished Capistrano had a UI, an audit trail, a one-click rollback, or a way to grant a junior engineer "deploy to staging only" without giving them root, this is the migration window.
Feature parity: Capistrano to DeployHQ
Everything you can do with cap production deploy you can do in DeployHQ. The mechanism changes; the contract does not.
| Capistrano | DeployHQ |
|---|---|
deploy.rb recipe |
DeployHQ project (web-configured, version-controlled by us) |
:stages (production, staging, qa) |
Environments per project |
current/ symlink switch |
Atomic deploy with automatic symlink swap |
:linked_files, :linked_dirs |
Shared paths configured once per environment |
before / after task hooks |
SSH commands tied to deploy lifecycle |
cap production deploy:rollback |
One-click rollback to any prior deploy |
:repo_url (any Git remote) |
GitHub, GitLab, Bitbucket, self-hosted Git, SVN, Mercurial |
cap production deploy:check |
Pre-deploy validation and dry-run preview |
| Manual SSH key management | Per-server keys, audit-logged |
:keep_releases cleanup |
Configurable release retention per environment |
What DeployHQ adds that Capistrano never did
| Capability | Why it matters |
|---|---|
| Web UI plus REST and GraphQL API | Deploy from a browser, a CLI, or a CI step. No cap binary to install. |
| Audit log of every deploy | Who deployed what, when, from which branch, with which commit hash. |
| Build pipelines | Run bundle install --deployment, npm ci && npm run build, composer install --no-dev once on our infrastructure — not on every server. |
| AI deploy error explanation | When a deploy fails, the failed step is summarised in plain English with a likely fix. |
| DeployHQ CLI | Ship a deploy from your terminal: deployhq deploy production. |
| Per-environment permissions | Grant deploy-to-staging without granting deploy-to-production. |
| Optional Managed VPS (beta) | If you don't already have a server, provision a DigitalOcean droplet inside DeployHQ in two clicks. SSH keys handled automatically. |
Migration in three steps
1. Connect your repository
Point DeployHQ at the same Git (or SVN, or Mercurial) URL you have in :repo_url. Read-only deploy keys are generated automatically. No git binary on the target server — DeployHQ checks out your code on our build infrastructure.
2. Recreate your stages as environments
Each Capistrano stage becomes a DeployHQ environment. Servers, paths, and shared files map directly:
set :deploy_to, "/var/www/app"becomes the environment deploy path.set :linked_dirs, %w(log tmp/pids)becomes shared paths.set :linked_files, %w(.env config/master.key)becomes shared files.
3. Translate hooks to SSH commands
Every before / after task in deploy.rb becomes an SSH command tied to a deploy stage (before upload, after upload, before changing symlink, after deploy). The Rails capistrano-rails gem's db:migrate, assets:precompile, and puma:restart become three SSH commands you wire once and never touch again.
For most projects, end-to-end migration is a half-day. For a multi-stage Rails app with Sidekiq, asset precompilation, and a database migration step, plan a day.
We also offer concierge migration assistance on Pro and above — send us your deploy.rb and we will rebuild the project with you on a screenshare.
Pricing snapshot
| Plan | Price | What you get |
|---|---|---|
| Solo | EUR 9 / month | 1 user, unlimited deploys, atomic releases, rollback |
| Pro | EUR 19 / month | Unlimited team members, agents, AI error explanation, all integrations |
| Enterprise | Custom | SSO, audit retention, SLA |
For a team that previously paid zero for Capistrano (open source), the line item you are buying is reduced operational risk — no more 2 a.m. "the deploy hung halfway and the symlink is wrong" pages. You can also add a Managed VPS as a billed add-on if you don't have a server, replacing one of your DigitalOcean line items rather than adding a new one.
What teams ask before they switch
Will my custom Capistrano tasks survive? Yes. Anything that runs over SSH on the target server runs identically — it is just configured in the dashboard instead of deploy.rb.
Can I keep using my existing servers? Yes. DeployHQ deploys to any SSH-reachable host. Bring your own VPS, dedicated box, or cloud instance.
Do you support multi-server deploys? Yes. Add multiple servers to one environment; DeployHQ deploys to all of them in parallel with the same atomic symlink swap.
What about my Rails-specific gems (capistrano-rails, capistrano-rbenv, capistrano-puma)? Their behaviours map to DeployHQ build pipelines (asset precompile, bundle install) and SSH commands (puma restart, db migrate). You do not reinstall the gems — you replicate what they did.
What if I want to roll back? One click. DeployHQ keeps your last N releases on the server (you configure N). Rollback flips the symlink back. No cap deploy:rollback required.
Start your migration
Start a free DeployHQ project — connect your repo, point at one server, and deploy in under 15 minutes. No credit card. If you are migrating a production system and want a hand, contact us about concierge migration and we will walk you through it.
If you also need a server, the Managed VPS beta provisions one inside the same dashboard.
Capistrano is a trademark of its respective maintainers. DeployHQ is not affiliated with the Capistrano project. We just ran our own deploys on it for a long time, and we know what graduating from it should look like.