Skip to content
Shipped®

Playbook / 02

The toolkit

Linux, Docker, Kamal and Kamal Proxy. A short list of tools, small enough to learn properly and steady enough that we rarely have to think about them.

We pick tools that have been around long enough to be dull. Each one on this page has a long track record. None of them made the list because they were trending.

Linux (Debian stable)

Every server we run starts with Debian stable. It’s the least surprising operating system we know. Updates show up on a steady rhythm, big releases come every couple of years, and the upgrade notes are actually readable.

We skip the specialised container operating systems. They’re built for large clusters juggling many tenants. On one dedicated machine, an ordinary Linux install is easier to reason about and easier to repair.

Docker

Docker is how we package apps. It’s not a statement, it’s just the common format software ships in now. Almost everything we deploy already has an official image, and when it doesn’t, we build a small one ourselves.

We don’t run Kubernetes. It’s a fine tool when you have dozens of machines and workloads that shift around between them. A single server running a few apps doesn’t need a scheduler, it needs to stay up.

Kamal

Kamal handles our deploys. It was built by the 37signals team for exactly our situation: a few Docker hosts and a desire not to babysit them. New releases are health-checked before they get traffic, and if a check fails, the old version stays in place.

A lot of incidents start with a deploy. Kamal takes the manual steps out of that moment, and rolling back is one command instead of a scramble.

Kamal Proxy

Kamal Proxy ships alongside Kamal 2. It listens on 80 and 443, handles certificates through Let’s Encrypt, and routes each hostname to the right container. During a deploy it switches traffic over without dropping requests.

In the past we’d have used Caddy or Traefik for this. Kamal Proxy was made for the way Kamal works, so it fits with less glue.

What’s not in the toolbox

Just as important as what we use:

  • No Kubernetes, for the reasons above.
  • No serverless platforms (Lambda, Cloud Run). The bills are hard to predict and the code is hard to move.
  • No closed platform layers sitting between us and the server. If we can’t see what’s running, we won’t run it.
  • No dependence on one CI vendor. Kamal deploys from a laptop or a CI runner, so an outage elsewhere doesn’t stop us shipping a fix.

Dull tools, sharp results.

Up next in the playbookSecurity basics

Say hello

Want this playbook working on your next project?

Tell us what you're building and where it stands today. We'll reply with a scoped first step, using the same process and toolkit described on these pages.

How it starts

  1. 01A real person reads your note before the next working day ends.
  2. 02You get straight answers and a few sharp questions back.
  3. 03If we can help, we map out a first release on a 30-minute call.