Capistrano
No Change
hold
Capistrano. Is a Ruby remote-deployment DSL: SSH into servers, run recipes (cap deploy), symlink releases; classic 2000s Ruby on Rails ops.
Summary
Why hold: serial SSH orchestration with mutable servers is the opposite of reconciled desired state. Recipes become tribal knowledge; rollbacks depend on symlink tricks; secrets and host lists rot in repo or .cap config.
Historical credit: helped teams practice repeatable deploys before modern DevSecOps, but that problem is better solved today without Capistrano.
Use instead
| Need | Prefer |
|---|---|
| Configure existing VMs | Ansible (adopt, last-resort second touch) |
| Provision cloud shape | Terraform + Declarative IaC |
| Run the app | Kubernetes + ArgoCD (GitOps CD) |
| Legacy Rails monolith | Strangle to containers/CI; don’t extend Capistrano |
Details
- Imperative IaC: same failure mode as Imperative IaC generators; hard to review, hard to test, hard to audit.
- Migration: freeze Capistrano recipes; mirror deploy steps in pipeline + declarative infra; retire SSH-based deploy users when apps move to K8s or immutable images.