{"slug":"tako-vs-kamal","url":"https://tako.sh/blog/tako-vs-kamal/","canonical":"https://tako.sh/blog/tako-vs-kamal/","title":"Tako vs Kamal","date":"2026-04-05T00:00","description":"How Tako and Kamal approach self-hosted deployment differently — Docker vs native processes, registries vs SFTP, and what each gets right.","author":null,"image":"c6cf08bce0d2","imageAlt":null,"headings":[{"depth":2,"slug":"at-a-glance","text":"At a glance"},{"depth":2,"slug":"where-kamal-shines","text":"Where Kamal shines"},{"depth":2,"slug":"where-tako-is-different","text":"Where Tako is different"},{"depth":3,"slug":"no-docker-no-registry","text":"No Docker, no registry"},{"depth":3,"slug":"a-real-proxy","text":"A real proxy"},{"depth":3,"slug":"local-development-included","text":"Local development included"},{"depth":3,"slug":"scale-to-zero","text":"Scale-to-zero"},{"depth":3,"slug":"lighter-secrets","text":"Lighter secrets"},{"depth":2,"slug":"different-tools-different-ambitions","text":"Different tools, different ambitions"}],"markdown":"We love what DHH and 37signals have done for self-hosted deployment. Kamal made \"deploy to your own servers\" cool again — and at 14k GitHub stars, it's the most prominent CLI deploy tool out there. If you're running apps on your own hardware, you've probably looked at it. We certainly did.\n\nTako does the same job differently. Both tools get your code onto your servers via SSH with zero-downtime deploys. But the architecture underneath is almost entirely different, and the long-term ambitions diverge too.\n\n## At a glance\n\n| | **Kamal** | **Tako** |\n| ---------------------- | ------------------------------- | ------------------------------------------------------ |\n| **Deploy method** | Docker build → registry → pull | Build locally → SFTP upload |\n| **Server requirement** | Docker engine | Just a Linux box |\n| **Proxy** | kamal-proxy (Go) | Pingora (Rust, Cloudflare) |\n| **CLI language** | Ruby | Rust |\n| **Config format** | YAML (`deploy.yml`) | TOML ([`tako.toml`](/docs/tako-toml)) |\n| **Local dev** | None | Built-in HTTPS + DNS ([`tako dev`](/docs/development)) |\n| **SDK** | None (health check endpoint) | [JS/TS and Go SDKs](/docs) |\n| **Scale-to-zero** | No | Yes, with cold start |\n| **Secrets** | Adapter-based (1Password, etc.) | Encrypted locally, passed via fd 3 |\n| **Stars** | ~14k | New kid on the block |\n\n## Where Kamal shines\n\nKamal deserves a lot of credit. Before Kamal, the self-hosted deploy space was mostly Dokku and a handful of smaller tools. DHH and 37signals made people rethink the cloud default — and that's something we deeply appreciate, because it's the same belief that drives Tako.\n\nKamal's biggest strength is Docker itself. If your team already runs Docker in production and has a container registry, Kamal slots right in. You write a Dockerfile, Kamal builds it, pushes it, and pulls it onto your servers. The container is the artifact — reproducible, isolated, portable.\n\nThe ecosystem is real. Kamal supports accessories (databases, Redis) as Docker containers alongside your app. It has adapters for 1Password, AWS Secrets Manager, and Bitwarden. The 37signals team runs their own production infrastructure on it — HEY, Basecamp, and more — which means it's genuinely battle-tested.\n\nAnd kamal-proxy, their custom Go reverse proxy, handles the zero-downtime dance well: health check the new container, route traffic, drain the old one, clean up.\n\nFor Rails teams especially, it's a natural fit. Rails 7.1+ ships with a `/up` health check endpoint out of the box, and Kamal's conventions align perfectly with Rails conventions.\n\n## Where Tako is different\n\n### No Docker, no registry\n\nKamal's deploy pipeline has three network hops: build the Docker image, push it to a registry, then pull it onto each server. That registry — whether Docker Hub, GHCR, or ECR — is an external dependency that adds latency, cost, and a failure point.\n\nTako skips all of that. You build locally, and the artifact goes straight to the server over SFTP. No registry account, no image layers, no Docker daemon on the server. The only requirement is a Linux box with SSH access.\n\n```d2\ndirection: right\n\nkamal: Kamal {\n direction: down\n\n build: Docker build\n registry: Registry\n server: Server pull\n\n build -> registry: push\n registry -> server: pull\n}\n\ntako: Tako {\n direction: down\n\n build: Local build\n artifact: Build artifact\n server: Server\n\n build -> artifact: bundle\n artifact -> server: SFTP\n}\n```\n\n### A real proxy\n\nkamal-proxy is purpose-built for deployment coordination — health checks, connection draining, host routing. It does that job well, but it's not a production-grade reverse proxy. No HTTP/3, no advanced caching, no rate limiting. Teams that need those features put Nginx or Caddy in front of it.\n\nTako uses [Pingora](/blog/pingora-vs-caddy-vs-traefik), Cloudflare's Rust proxy framework. It's the same technology that handles a significant chunk of internet traffic. TLS termination, HTTP/2, WebSocket proxying, and caching are built into the same process — no extra layer needed.\n\n### Local development included\n\nKamal is a production deployment tool. Local dev is left to Docker Compose or whatever your team uses. There's no `kamal dev`.\n\nTako treats local dev as a first-class concern. [`tako dev`](/docs/development) gives you real HTTPS with trusted certificates, local DNS routing (`*.test`), and a proxy that matches production behavior. Your app runs the same way locally as it does on the server — same SDK, same process model, same routing.\n\n### Scale-to-zero\n\nKamal keeps your containers running. That's the right choice for always-on apps, but if you're running staging environments, internal tools, or low-traffic services, those containers still eat memory 24/7.\n\nTako supports [on-demand scaling](/docs/how-tako-works): instances spin down after an idle timeout and cold-start on the next request. For apps that don't need to be always-on, this is meaningful resource savings on a single server running multiple apps.\n\n### Lighter secrets\n\nKamal's secret management uses adapter files in `.kamal/secrets` that integrate with external vaults. Powerful if you're already using 1Password or AWS Secrets Manager, but it's another configuration surface to maintain and debug.\n\nTako encrypts secrets locally with AES-256-GCM and delivers them to app instances via file descriptor 3 at spawn time — never written to disk on the server, never in environment variables that might leak to logs. It's simpler to set up: [`tako secrets set`](/docs/cli) and you're done.\n\n## Different tools, different ambitions\n\nKamal is a great deploy tool, and we mean that sincerely. It's mature, well-maintained, and backed by a team that runs serious production infrastructure on it. If Docker is already part of your workflow, Kamal is an excellent choice.\n\nTako starts from a different place — no Docker, native processes, Pingora proxy — but the bigger difference is where it's headed. Kamal is a deployment tool and does that job well. Tako is becoming a platform: the layer between your code and the internet. Today that's deployment, routing, TLS, secrets, and local dev. Tomorrow it's WebSocket channels, queues, workflows, and more — backend primitives your app would otherwise need separate services for.\n\nCombined with [multi-server environments](/docs/deployment) and Cloudflare smart routing, Tako lets you build your own edge network on commodity VPS boxes. Think Fly.io, but on your own hardware.\n\nThe question isn't just \"Docker or no Docker\" — it's whether you want a deploy tool or a platform. We're grateful Kamal helped prove that self-hosting is a real option. We're building on that momentum.\n\nCheck out [how Tako works](/docs/how-tako-works) for the full architecture, or the [deployment docs](/docs/deployment) to see it in action."}