For years, I treated Kubernetes like the grown-up version of deployment: inevitable, powerful, and—if you ignored the operational pain—almost magical. Then I tried Kamal. The premise is so straightforward it feels suspicious: build a deployable container, point at a few servers, and roll out with near-zero downtime… without an orchestrator. After using it, I stopped assuming that “serious companies” need Kubernetes. I started asking a more honest question: do you need orchestration, or do you need a deploy process that doesn’t hate you?

The problem Kubernetes quietly teaches you to ignore⌗

Kubernetes is often sold as a platform for running workloads. In practice, most teams adopt it to solve a different problem: they want consistent, repeatable deployments across environments—dev, staging, prod, plus a cloud of edge cases in between.

But Kubernetes doesn’t eliminate deployment complexity; it relocates it. You trade “write a deployment script” for “design a deployment strategy across controllers,” “choose rollout parameters,” “understand service discovery and readiness gates,” and “learn how to debug the moment your cluster is healthy but your app isn’t.”

Even the people who love Kubernetes eventually end up writing glue: pipelines that generate manifests, conventions for image tags, scripts for migrations, and tribal knowledge about rollbacks. The more you rely on the cluster for everything, the more deployment becomes an exercise in understanding the platform’s behavior rather than the app’s behavior.

Kamal’s appeal is that it refuses to make deployment a rite of passage.

What Kamal actually is (and what it isn’t)⌗

Kamal is a deployment tool for containerized applications to bare servers. No orchestrator required. No Kubernetes. No Helm. No controllers. The conceptual model is closer to Docker Compose than it is to K8s:

  • You define what to run.
  • You build images.
  • You deploy them to one or more servers.
  • You roll out changes using a strategy that aims for no downtime.

If Kubernetes is “describe the desired state of your entire system,” Kamal is “ship this release to these machines, safely.”

It also bakes in a few things teams always end up bolting on:

  • Zero-downtime rolling deploys (the practical kind: instances come up, traffic shifts, old ones drain)
  • Built-in SSL (so you’re not reinventing HTTPS automation)
  • A deployment workflow designed around real apps, not abstract workloads

The most telling part is the positioning. Kamal doesn’t ask you to run your whole world. It asks you to deploy your app. That means your mental model stays attached to your software instead of drifting into platform mechanics.

The “it’s just a script” philosophy that hits a nerve⌗

The first thing you notice about Kamal is how calm it feels. Kubernetes deployments can be thrilling—until you start worrying about resource requests, readiness probes, rollout controllers, and the difference between “pod running” and “app actually serving traffic.”

Kamal is suspiciously simple. And that’s the point.

Think about what you truly need for most production deployments:

  1. Build a new artifact (container image).
  2. Start the new version somewhere.
  3. Verify it’s healthy.
  4. Shift traffic to it.
  5. Stop the old version without breaking users.
  6. Make rollback predictable.

That’s basically it. Everything else—ingress controllers, service meshes, autoscalers—may be useful, but it’s not required for safe, repeatable rollouts of a typical web app.

Kamal leans into that reality. It’s what Docker Compose would become if it grew up just enough to deploy across multiple machines with disciplined rollout behavior.

And yes, it can feel offensive if you’ve spent years mastering Kubernetes. You built expertise. You paid the tax. Seeing a tool bypass most of that can look like a shortcut.

But shortcuts aren’t the issue. Abstractions that don’t match your problem are.

A concrete rollout example: the sane kind of “zero downtime”⌗

Let’s say you run a Rails app in containers across three servers behind a load balancer. With Kubernetes, your rollout story might involve:

  • updating a Deployment spec,
  • letting the controller create pods,
  • ensuring readiness probes are correct,
  • waiting for the rollout strategy to complete,
  • and hoping your traffic routing behaves exactly as expected.

With Kamal, the story is narrower. The deploy is centered on application instances:

  1. Deploy to a subset of servers
    • Kamal brings up the new release alongside the old one.
  2. Health checks gate progression
    • If the new container isn’t serving properly, the rollout won’t just “pretend” it’s fine.
  3. Traffic shifts cleanly
    • Clients start hitting the new instances.
  4. Old instances drain and stop
    • You minimize disruption without requiring the entire system to be re-platformed.

This model is not about theoretical correctness; it’s about keeping the website usable during updates. If your app is mostly stateless and your dependencies are stable, that’s often exactly what you need.

And the best part? When things go wrong, you can reason about them like a deploy issue, not like a distributed systems seminar.

Why DHH’s comfort matters (and why it shouldn’t be a surprise)⌗

Kamal isn’t just a toy for hobbyists. The 37signals team reportedly runs Hey and Basecamp using Kamal without Kubernetes. That detail matters less as a status symbol and more as a validation of the underlying premise: you can run serious production workloads with a deployment workflow designed to do the job, not to showcase architecture.

But here’s the part I find most useful as a lesson: their choice suggests they didn’t chase complexity for its own sake. They likely asked the same question many teams eventually reach:

Are we actually deploying our application, or are we operating our infrastructure?

Kubernetes can be a great platform, but it’s also a commitment. It’s not merely “a tool”; it’s a way of structuring work, skills, debugging, and cost. If your workload doesn’t require the benefits of orchestration, then Kubernetes becomes an elegant answer to a question you didn’t ask.

Kamal answers the question you did ask: “How do we roll out changes without breaking production?”

When you should choose Kamal—and when you shouldn’t⌗

Here’s my opinionated rule of thumb:

Kamal fits best when…⌗

  • Your app is web-facing (or otherwise straightforward to route)
  • Your deployment unit is essentially one release → one container image
  • You want multi-server deployments without building a platform team
  • You prefer strong deploy guarantees (rolling updates, HTTPS, predictable rollbacks) over deep cluster-level control

Examples: Rails apps, Node services, background workers with manageable routing, and most “normal” containerized web systems.

You might still want Kubernetes when…⌗

  • You need complex scheduling across heterogeneous resources
  • You run workloads that demand fine-grained autoscaling and orchestration semantics
  • You’re building a platform used by multiple teams with diverse requirements
  • You want cluster-native primitives as first-class features (for example, advanced networking models)

None of that is “bad.” It’s just different. Kubernetes is incredible when you genuinely want a distributed runtime and you’re willing to operate it.

But if your primary pain is “we can’t deploy safely,” Kamal targets that directly.

The practical takeaway: stop making deploys a platform problem⌗

After using Kamal, the biggest mindset shift I had wasn’t technical—it was cultural.

Stop asking, “Do we have Kubernetes?” Start asking:

  • Do we have a release workflow that makes rollback boring?
  • Can we deploy across servers without a fragile web of custom scripts?
  • Do we have health checks and traffic shifting that match how users experience the system?
  • Are we building abstractions we can’t explain to a new teammate?

Kamal’s strength is that it keeps deployment close to the app’s reality. You get a disciplined rollout mechanism, not an ecosystem you have to learn to operate.

And in many teams, that’s the difference between shipping confidently and constantly fearing the next production change.

Conclusion: Maybe the orchestrator isn’t the point⌗

Kubernetes is powerful, but it isn’t automatically the answer to “safe deployments.” Kamal is a reminder that many production problems reduce to a well-designed release process: roll forward without downtime, roll back without drama, and keep HTTPS from becoming a permanent project.

If your infrastructure goal is “run apps,” Kamal will feel almost refreshingly honest. It’s not trying to be your platform. It’s trying to get your code into production—cleanly—and let you get back to building.