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](https://www.deployhq.com/compare/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](/support/migrating-to-deployhq/migrating-from-mina-to-deployhq). If you have already moved past Capistrano to Kamal and are now reconsidering, see [Migrating from Kamal to DeployHQ](/support/migrating-to-deployhq/migrating-from-kamal-to-deployhq). If you work in PHP, the equivalent guide is [Migrating from Deployer to DeployHQ](/support/migrating-to-deployhq/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](/support/migrating-to-deployhq/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](https://www.deployhq.com/support/deployments/zero-downtime-deployments/setting-up-zero-downtime-deployments) |
| `:linked_files`, `:linked_dirs` | Shared paths configured once per environment |
| `before` / `after` task hooks | [SSH commands](https://www.deployhq.com/support/ssh-commands) tied to deploy lifecycle |
| `cap production deploy:rollback` | [One-click rollback](https://www.deployhq.com/support/deployments/rolling-back-a-deployment) 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](https://www.deployhq.com/support/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](https://www.deployhq.com/support/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](https://www.deployhq.com/support/managed-vps-hosting) (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](https://www.deployhq.com/support/managed-vps-hosting) 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.