Deploying containers over SSH without any infrastructure is what 37signals' Kamal does.
Kamal philosophy
Originally known as MRSK, Kamal was born from 37signals' departure from cloud and represents a strong position about how deployment is supposed to be done: as a command line utility, not as a platform. deploy.yml file in your repo specifies servers, roles and environment; running kamal deploy builds an image, pushes it to registry and boots containers over SSH with zero-downtime cutover performed by its proxy. No server-side control plane exists whatsoever, apart from Docker.
For the use case it was designed for (a team deploying one application to managed servers, specifically, in their case, Rails monoliths), Kamal is sleek, fast and very transparent - everything it does can be seen in your repository.
The trade-off: no shared state, no shared view
Without the presence of a platform, there is nothing to see. There is no dashboard, no deploy history except your scrollback in terminal window and commits in git log, no permissions for the team, no log aggregation, no database management. Each project comes with its own deploy.yml, secrets management is your responsibility (with help from .env and secrets storage), and every deployer requires Docker registry credentials and SSH access to production.
This scales down nicely, one repository, two people, full transparency, and does not scale up well. Ten repositories means ten configurations that will diverge over time. Junior developer or client wanting to ask "was staging deployed?" cannot use any kind of UI. Database management is clearly not Kamal’s concern: it starts accessories for you.
When a platform succeeds
Many projects and repositories: one dashboard and one mental model vs multiple deploy.yml files
Multi-talent teams: the non-command line friends and clients have access to deploys and logs without SSH
Databases are managed services and S3 backed up periodically, not hacked together from crons
One click template for various support components (analytics, queues, monitoring, etc.)
Webhook deploys on push without sharing the registry and SSH keys across all repositories in CI
Unlimited members with roles by project, valuable as soon as you meet a contractor or client
When Kamal wins
Kamal’s arguments about the need for a single application, infrastructure as code culture, and for everything deployed to be version-controlled: Kamal is absolutely correct here. It is also a more transparent tool as well, since there is nothing about the underlying platform that you need to figure out, only the commands it executes.
Also, they fit nicely together
This is not an either/or proposition. Some organizations have Kamal in place for the custom monolith that they want to control completely and use Peon for all other tasks including databases, backups, internal work, customer projects, and the long tail of services. They both talk in plain Docker over SSH, and thus they do not clash and one can shift between them as required.
Top comments (0)