The stack

The technology choices we make are deliberately boring. Every tool below was chosen because it has earned its place over years, not because it appeared on a conference slide last quarter.

Linux (Debian stable)

The base OS for every server we run. Debian stable is the operating system equivalent of a workshop bench: not exciting, but it doesn’t move while you’re working on it. Security patches arrive on a predictable schedule. Major version transitions are infrequent and well-documented.

We do not use container-only OSes (CoreOS, Talos, RancherOS). They’re optimized for a problem we don’t have, orchestrated multi-tenant clusters. For a single-tenant dedicated server, a normal OS is simpler and easier to operate.

Docker

For application packaging. Docker isn’t a fashion choice, it’s the lingua franca of how applications ship in 2026. Every piece of software in our managed stack publishes official Docker images. We use them as-is or build slim production images on top.

We do not orchestrate with Kubernetes. Kubernetes is excellent for the problem it solves; that problem is “we have a fleet of nodes and a dynamic workload that needs to be placed across them.” A single dedicated server with five applications is not that problem.

Kamal

For deploys. Kamal is the deployment tool by the team at 37signals, designed to turn the “one or a few Docker hosts” pattern into a first-class workflow. Health-checked rolling deploys, automatic rollback on failure, atomic config + image releases.

Most outages happen during deploys or in the immediate aftermath. Kamal’s design, every release is health-checked before it takes traffic, rollback is a single command, eliminates entire classes of failure that come from manual processes.

Kamal Proxy

The reverse proxy that ships with Kamal 2. It binds the public 80/443 ports, terminates TLS via Let’s Encrypt, and routes traffic by Host header to the right container. It also handles zero-downtime cutovers during deploys.

Before Kamal 2 we’d have reached for Caddy or Traefik. Kamal Proxy is purpose-built for this pattern and integrates tightly with Kamal’s deploy lifecycle, so we use it.

What we don’t use

This list is shorter than the previous one but worth being explicit about:

• No Kubernetes, for the reasons above.
• No managed serverless (Lambda, Cloud Run), the lock-in and the surprise billing don’t fit our principles.
• No proprietary “platform” layers, we never want to be unable to read what’s running on a server we operate.
• No CI-only deploys, Kamal runs from a workstation or a CI runner; either works. We don’t depend on a specific CI vendor being healthy to push a fix.