What does Kamal need on a target server before it can deploy your app there, and how does the container image actually get onto that host?

## What Kamal is Kamal (from 37signals; it was called MRSK before version 1.0) deploys containers to plain servers you already own. It is a command-line tool, not a service: there is no scheduler, no cluster membership, and nothing of Kamal's running permanently on the hosts except the containers it starts. You run `kamal deploy` from a laptop or, more usually, from a CI job, and it does over SSH exactly what you would have done by hand with `docker` commands — just consistently, in the right order, on every host at once. ## The three things a host needs 1. **An SSH login that can use Docker.** Kamal connects as the user named under `ssh: user:` (root by default) and runs `docker` as that user. If Docker is missing, Kamal 2's `kamal server bootstrap` — invoked as part of `kamal setup` — installs it. That is the entire server-side prerequisite list. 2. **A reachable container registry, with credentials.** Docker Hub, GHCR, ECR, or a private one. The `registry:` block names the username and the environment variable holding the password, and Kamal runs `docker login` on each server so it can pull. 3. **Config in the repo.** `config/deploy.yml` holds the service name, image name, the `servers:` list grouped by role, the registry, and environment variables. Secrets live outside it — in `.kamal/secrets` in Kamal 2.x, or in a `.env` file pushed with `kamal env push` in 1.x. ## How the image travels: through the registry, not the SSH pipe This is the part candidates most often get wrong. Kamal builds the image locally (or on a remote builder host, via `builder: remote:`), tags it with the git revision, and **pushes it to the registry**. Each server then **pulls** that tag. The registry is the fan-out point, which is why the servers need credentials of their own and why `builder: arch:` matters — building on an Apple Silicon laptop for amd64 servers produces an image the hosts cannot run unless you say so: ```yaml builder: arch: amd64 ``` ## What actually runs during a deploy `kamal deploy` opens SSH sessions to every host listed under `servers:` and executes docker commands there. Servers are grouped by **role**: the `web` role is the one the proxy fronts; other roles such as `job` run the same image with a different `cmd:`. Longer-lived dependencies — Postgres, Redis — are declared as `accessories:` and booted separately with `kamal accessory boot`, deliberately outside the app's release cycle. Kamal takes a deploy lock first so two deploys cannot interleave, and it records what it ran, which you can read back with `kamal audit`. Day-to-day inspection uses the same shape of command: `kamal app logs -f`, `kamal app exec`, `kamal details`. ## What is deliberately absent No agent process, no control plane, no cluster API, no scheduler, no CRDs. The API *is* your SSH login. That has one important consequence worth saying out loud in an interview: whoever can deploy holds SSH credentials to production. That is why teams normally run Kamal from a CI job with a dedicated deploy key rather than from individual laptops, and why the blast radius of that key is the thing to think hardest about. It is also the honest tradeoff of the whole tool — you trade a control plane you have to operate for a credential you have to protect.