Kamal vs Coolify: How Much Platform Should Actually Run on Your Server?

Two of the most popular self-hosted deploy tools in 2026 give opposite answers to the same question: how much platform should actually run on the machine? Kamal, the SSH-driven deployer from 37signals, says almost nothing — your app, a tiny proxy, and whatever accessories you declare. Coolify, the open-source Heroku alternative with over 50,000 GitHub stars, says the whole platform — dashboard, database, job queues, reverse proxy, and a GitHub App that spins up a preview environment for every pull request.

Both are right for somebody. Both are wrong for somebody. Here is the concrete side-by-side, what each one costs you in server footprint and operational surface, and where a third option — a Render-compatible API with machine-readable state and no heavyweight dashboard — splits the difference.

The comparison up front​

If that table already told you which camp you are in, the rest of this post is the receipt: what each row actually costs a team in practice.

Kamal: nothing to operate, nothing to query​

Kamal comes from 37signals, the company behind Basecamp and HEY, and it shows. It is a Capistrano-descended deployment script in spirit: you describe servers and accessories in config/deploy.yml, keep secrets in .kamal/secrets, and run kamal deploy from your laptop or CI. Over SSH, Kamal builds (or pulls) your image, starts new containers, waits for your health check to return 200, and flips traffic with zero downtime. When the deploy finishes, Kamal goes away. There is no daemon, no dashboard, no platform database keeping state about your apps — the desired state lives in your repo's YAML, and the actual state lives in Docker on each box.

Kamal 2.0 sharpened this model considerably. It replaced Traefik with kamal-proxy, a purpose-built proxy that handles zero-downtime container switching and automatic HTTPS via Let's Encrypt, and it added first-class support for running multiple apps on the same server. It now ships by default with Rails 8, which tells you who the assumed operator is: a developer comfortable owning a deploy.yml, not a platform team running a control plane.

What that buys you is radical simplicity in production. There is no dashboard to patch, no control-plane database to back up, no background worker whose queue can silently wedge at 3 AM. The attack surface of your platform layer is a proxy and an SSH daemon. A 1 GB VPS that would wheeze under a full PaaS runs a Kamal-deployed app just fine, because between deploys there is no platform tax at all.

What it costs you is everything a control plane would have done. There are no preview environments: if you want per-branch review apps, you hand-roll them with Kamal destinations and your own DNS automation, and you own that glue forever. There is no webhook receiver, so "deploy on push" means wiring CI yourself. There is nothing to query — no API that can answer "what is deployed where, and is it healthy?" An AI agent, a status page, or a teammate's script all face the same interface: SSH into the box and run docker ps. For one or two apps and a developer who likes it that way, this is a feature. For a team whose deploy process needs to be observable and automatable by anything other than the person who wrote the YAML, it is a ceiling.

Coolify: the whole platform, previews included​

Coolify is the opposite bet, and its ~54,000 GitHub stars say the bet is popular. You install it on a server and it brings the Heroku experience with it: a web dashboard, a database tracking every project, environment, and deployment, background workers executing builds, and Traefik terminating TLS and routing traffic. Connect a GitHub App and pushes auto-deploy; open a pull request and Coolify builds a preview deployment at a templated URL like {{pr_id}}.preview.yourdomain.com, then tears it down when the PR closes. Databases and services — Postgres, Redis, and dozens more — install from a catalog with scheduled backups.

That control plane is also a genuine automation surface, which matters more than the dashboard screenshots suggest. Coolify exposes a REST API with an OpenAPI spec, ships an MCP server with dozens of tools for AI assistants, and has community Terraform providers managing 50+ resource types. "What is deployed where, and is it healthy?" is an API call. An agent can list applications, trigger a deploy, read logs, and manage preview environments without ever touching SSH. Whatever you think of dashboards, machine-readable state is the difference between a deploy tool and infrastructure that other software can operate.

The cost is everything Kamal refused to run. The control plane idles at roughly 800 MB of RAM before your first app container starts, which is why the practical minimum is a 2 GB VPS and 4 GB is the comfortable recommendation. That is a real line item on small machines: on a 4 GB box, Coolify's own footprint eats a fifth of your memory before you have served a single request. You also inherit a second production system to operate — the platform itself needs updates, its database needs backups, and its dashboard is a login page on your infrastructure that you must keep patched and preferably off the public internet. Preview environments multiply this honestly: every open PR is real containers consuming real CPU and RAM on your box, which is exactly what you want for review apps and exactly what surprises you on the invoice-free but finite VPS you already owned.

The gap both leave open​

Notice what neither tool gives you. Kamal has no resident footprint but also no queryable state: your deployment knowledge lives in a developer's head plus a YAML file. Coolify has full queryable state but demands a resident control plane — dashboard, database, workers — that you operate forever to get it.

That coupling is a historical accident, not a law of nature. "Machine-readable deploy state" does not require "a Laravel app and a database idling on my server." The state a team (or an agent) actually needs — which services exist, what revision each runs, whether the last deploy succeeded, what the logs say — is a small API surface. And the operations that matter day to day — deploy this revision, roll back to that one, spin up an ephemeral environment — are a small verb surface too. Render proved the shape of that surface years ago: services, deploys, environment variables, and preview environments as REST resources you can drive from CI, scripts, or agents without opening a browser.

A Render-compatible API on infrastructure you own is the middle path the table above is missing: Kamal-shaped footprint with Coolify-shaped automatability. Nothing heavy idles on the box — no dashboard to patch, no control-plane database eating a fifth of your VPS — but every deploy, rollback, and environment is still a resource an API client can read and mutate. The GitHub App pattern Coolify popularized (push to deploy, PR to preview) works just as well against API resources as against a dashboard; the dashboard was never the load-bearing part. And for teams starting to let AI agents deploy and operate apps, the requirement was never "a prettier UI" — it is structured state, stable identifiers, and verbs with predictable effects, which is precisely what an API-first design provides and precisely what SSH-and-YAML cannot.

Which one should you pick?​

The honest answer depends on what your team needs to be true the week after the deploy works, not the afternoon it first succeeds:

• Pick Kamal if you run one or a few apps, you are comfortable in deploy.yml and SSH, you do not need preview environments, and nothing but a human needs to interrogate deploy state. Solo developers and small Rails-flavored teams live here happily.
• Pick Coolify if you want Heroku semantics — push to deploy, click to provision Postgres, automatic per-PR previews — your team benefits from a shared visual view of every environment, and you can spare 2–4 GB of RAM plus the ongoing care a control plane needs. Teams with non-ops developers reviewing work in preview apps live here happily.
• Pick the API middle path if you want Coolify's automatability (agents, CI, scripts driving deploys and previews as API calls) without Coolify's resident footprint, or Kamal's leanness without giving up queryable state. Small teams running on one modest VPS, and anyone building agent-operated infrastructure, should weigh this option hardest.

Whichever you choose, go in with eyes open about the real price. Kamal's price is paid in glue code and tribal knowledge the day someone asks for previews or API access. Coolify's price is paid in RAM and platform maintenance from day one. The middle path's price is maturity: API-first self-hosted platforms are younger than either extreme, so verify the endpoint coverage for your workflow before you commit.

The bottom line​

Kamal and Coolify are not really competing — they are the two endpoints of a spectrum every self-hosting team places itself on: how much platform runs on the machine versus how much the machine can tell you about itself. Kamal minimizes the first and forfeits the second. Coolify maximizes the second and charges you the first. The interesting space in 2026 is the middle that Render sketched and open source is now filling in: full machine-readable deploy state with close-to-zero resident footprint. That is where agent-operated, preview-driven workflows on owned hardware stop being a luxury purchase and start being the default.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.