{
  "$type": "site.standard.document",
  "description": "My practical Kamal vs Coolify comparison for solo SaaS apps: when I prefer one-command deploys, when a dashboard helps, and why I use Kamal with Hetzner.",
  "path": "/kamal-vs-coolify-for-a-solo-saas/",
  "publishedAt": "2026-05-29T01:12:00.000Z",
  "site": "at://did:plc:bryys25pc2fnagnyxqgsglhd/site.standard.publication/3mn26bjkkmh23",
  "tags": [
    "Web",
    "Tools"
  ],
  "textContent": "I get the Kamal vs Coolify question because both solve the same problem: \"I want to deploy to my own server without building a mini Heroku.\"\n\nI use Kamal for my SaaS apps because I want deployment to be a command in the repo, not another app I have to run.\n\nCoolify is still good. I just want different tradeoffs.\n\nWHAT KAMAL GIVES ME\n\nKamal is a CLI deploy tool. It reads config/deploy.yml, builds a Docker image, pushes it to a registry, SSHs into the server, starts the new container, waits for health checks, and swaps traffic through kamal-proxy.\n\nMy day-to-day command is still:\n\nkamal deploy\n\nMost of my workflow now runs through coding agents. I can tell an agent:\n\nRun tests, deploy with Kamal, then check the GitHub Pages or app health endpoint.\n\nThe deploy path, config, and error output are all text. The agent can read them without a special integration.\n\nKamal fits my solo SaaS codebases because it uses the tools I already use: git, Docker, SSH, tmux, scripts, and AGENTS.md.\n\nWHAT COOLIFY GIVES YOU\n\nCoolify is closer to a self-hosted PaaS.\n\nYou get:\n\n * a web dashboard\n * app creation flows\n * environment variable management\n * service templates\n * Git-based deploys\n * logs in the UI\n * databases and supporting services\n * an API for automation\n\nThat is useful if you want a platform experience on your own VPS.\n\nIt is also useful if you have people deploying who are not comfortable editing YAML and running CLI commands. A dashboard is easier to teach.\n\nThe tradeoff: Coolify itself becomes part of the system. You run your app, your database, and the deployment platform.\n\nThat can be fine. For me, it is one more moving part than I want.\n\nWHERE DEPLOYMENT STATE BELONGS\n\nWith Kamal, the important deployment decisions are in the repo:\n\nservice: myapp\nimage: ghcr.io/me/myapp\n\nservers:\n  web:\n    hosts:\n      - 123.45.67.89\n\nproxy:\n  ssl: true\n  host: myapp.com\n  app_port: 3000\n  healthcheck:\n    path: /health\n\naccessories:\n  db:\n    image: postgres:16\n    host: 123.45.67.89\n    directories:\n      - data:/var/lib/postgresql/data\n\nThat file can be reviewed, copied, diffed, and changed by an agent.\n\nWith Coolify, more of the deployment state is in the platform. PaaS-style tools work that way. You get a nicer UI, but the deploy system is less like the rest of my codebase.\n\nFor a team, that might be worth it.\n\nI want that config in git.\n\nWHAT THE AGENT CAN INSPECT\n\nThis is the part that matters once coding agents are in the loop.\n\nWhen a Kamal deploy fails, the agent can inspect the same things I inspect:\n\ngit diff config/deploy.yml\nkamal details\nkamal app logs --lines 200\nkamal proxy logs --lines 200\nkamal accessory logs db --lines 200\n\nThe agent can compare the deploy config with the Dockerfile, check whether the health endpoint exists, see whether a secret is missing, and make a normal code change.\n\nThat gives me a clean feedback loop. The deployment tool writes output to the terminal, the agent reads it, and the fix usually lives in the repo.\n\nWith a dashboard tool, some of the state is still inspectable through logs, config files, and APIs, but the platform becomes part of the process. If the fix is \"change this setting in Coolify\", I need that setting to be scriptable or I have to do it myself. I avoid that when I can.\n\nTHE COMMON FAILURE MODES ARE BORING\n\nMost deploy problems I hit are not exotic.\n\nThey are things like:\n\n * the Docker image builds, but the app exits because an env var is missing\n * the health check path returns 404\n * the app listens on localhost instead of 0.0.0.0\n * the database accessory is up, but the app has the wrong DATABASE_URL\n * a Vite build-time env var was only provided at runtime\n * the server is out of disk space because old images were not pruned\n\nKamal does not make these disappear. It just keeps the problem close to the code.\n\nFor example, if the health check fails, I can point an agent at the output:\n\nKamal deploy failed on the health check. Check the app port, health route,\nand container logs. Keep the fix scoped.\n\nThe prompt gives the agent enough context for a useful debugging pass. It can read config/deploy.yml, find the Fastify route, check the Dockerfile, and run the app locally if needed.\n\nThe same thing works for secrets. If a deploy fails because STRIPE_WEBHOOK_SECRET is missing, the agent can update the deploy config or tell me the secret needs to be added. It should not print the secret, and my AGENTS.md says that.\n\nKamal works well with repo instructions here. The deploy tool stays simple, and the guardrails are in text.\n\nWHY I PICKED KAMAL FOR STACKNAUT\n\nStacknaut is a one-server SaaS starter kit. It ships with Vue, Fastify, PostgreSQL, Docker, Terraform, and Kamal.\n\nI care that the deployment flow is part of the starter kit and part of the agent workflow.\n\nA coding agent can:\n\n * edit app code\n * update shared types\n * run checks\n * inspect config/deploy.yml\n * deploy with Kamal\n * read deploy errors\n * fix the problem\n * deploy again\n\nThe agent does not need browser automation or instructions like \"go to this page and press the deploy button.\"\n\nThat is the main reason I prefer Kamal.\n\nWHEN I WOULD CHOOSE COOLIFY\n\nI would choose Coolify if:\n\n * I wanted a self-hosted dashboard for multiple small apps\n * I was deploying projects that do not share a common repo pattern\n * I wanted templates for databases and services\n * I had non-CLI users deploying apps\n * I wanted Git push deploys managed by the platform\n * I wanted a deployment API around the platform\n\nCoolify is a better fit when you want the dashboard to be the thing you run.\n\nWHEN I WOULD CHOOSE KAMAL\n\nI choose Kamal when:\n\n * the app already has a Dockerfile\n * the team is comfortable with CLI deploys\n * deployment config should stay in git\n * I want a coding agent to reason through deploy failures\n * I want the server to stay simple\n * I do not need a platform UI\n\nFor solo SaaS work, this is my default.\n\nMY RULE\n\nIf I want a self-hosted Heroku-like dashboard, I would use Coolify.\n\nIf I want a boring deploy command that fits a codebase and an agent workflow, I use Kamal.\n\nStacknaut uses Kamal for this reason.\n\nWHAT I WOULD STILL BORROW FROM COOLIFY\n\nCoolify has nice ideas. I would not mind better visibility around running services, env vars, and logs.\n\nI handle that with smaller tools:\n\n * Better Stack for logs\n * uptime checks for public health endpoints\n * Telegram notifications for server jobs\n * tmux windows for deploys I want to watch\n * Kamal commands for app and accessory status\n\nIt is less polished than a dashboard. Fair enough. But I can swap any piece out without changing the deploy model.\n\nThe missing bit is usually a nice status page for everything on the server. I get close enough with commands:\n\nkamal details\nkamal accessory details\ndocker ps\ndf -h\n\nThose are not pretty, but they are scriptable. An agent can run them, paste the important lines into the session, and decide whether the problem is app health, disk space, a dead accessory, or something else.\n\nCoolify bundles more of that into one interface. I see the appeal. If I were running a small internal platform for other people, I would take that more seriously.\n\nFor my own projects, the command-line version wins because it is easier to automate. I can put the exact commands in AGENTS.md, a skill, or a script. The workflow survives if I change terminals, editors, or coding agents.\n\nIt also keeps onboarding simple. A new project has the same deploy file layout, the same commands, and the same failure paths as the last project. I do not need to remember which dashboard setting I clicked six months ago, or explain it again to an agent.\n\nFor my own apps, that is the tradeoff I want.",
  "title": "Kamal vs Coolify for a Solo SaaS"
}