Coolify, Kamal, or Just Push to Cloud Run? How We Pick Deployment for Each Client

Three Tools, Three Worldviews

You don’t need Kubernetes. Most teams in 2026 still don’t. The question is which non-Kubernetes deployment story fits the application you’re shipping.

Three options dominate the conversation:

• Coolify is a self-hosted PaaS. You run one Docker host, it gives you a Heroku-like UI, you click deploy.
• Kamal is a single-command tool that pushes your Docker image to one or many servers, manages SSL, does zero-downtime swaps.
• Cloud Run is Google’s serverless container platform. You give it an image, it gives you HTTPS, autoscaling, and pay-per-request billing.

Each one is the right answer for somebody. None of them is the right answer for everybody. We’ve shipped all three for different clients in the last twelve months.

Here’s how we pick.

What Each Tool Actually Is

Coolify is what Heroku would have been if Heroku were open source. Run it on a single Hetzner box (or a fleet), connect a Git repo, and it builds, deploys, and serves your app behind a managed reverse proxy with Let’s Encrypt SSL. Crossed 50,000 GitHub stars in 2025.

The core promise: Heroku-style developer experience without Heroku-style monthly bills. Databases, caches, cron jobs, and preview environments all live in the Coolify UI.

Kamal (specifically Kamal 2, released at Rails World 2024 and shipped with Rails 8) is what 37signals built to escape AWS for HEY and Basecamp. It takes your Dockerfile, ships the image to a fresh Linux server, sets up kamal-proxy (37signals’ purpose-built reverse proxy that replaced Traefik in Kamal 2), handles SSL via Let’s Encrypt, runs zero-downtime deploys, and manages secrets through 1Password, Bitwarden, AWS Secrets Manager, or several other backends. One command: kamal setup. One yaml file describes your whole deployment.

It does less than Coolify. That’s the point. There’s no UI. There’s no dashboard. There’s a config file, your code, and a CLI.

Cloud Run is the GCP serverless story. You build a container, push it to Artifact Registry, run gcloud run deploy, and you get a URL with autoscaling from zero to 1,000 instances per service (raisable via quota), integrated load balancing, IAM, and pay-per-100ms billing (or instance-based billing if you prefer flat-rate). Azure Container Apps is the closest analog on other clouds; AWS App Runner is in the same neighborhood but with more constraints (no scale-to-zero on the standard tier, fewer regions, weaker autoscaling story).

The trade-off: cold starts, no persistent disk, and a pricing model that gets expensive past sustained moderate traffic.

When We Pick Coolify

We pick Coolify when:

• The client wants a self-hosted PaaS with a UI their non-developer founder or operations lead can use.
• There are 5-30 services to manage (Django app, n8n automation, internal admin, a couple of databases, a Plausible instance).
• EU data residency matters and Hetzner or another sovereign provider has the right region.
• The team values “click around in a UI to add a service” over “edit a YAML file and run a CLI.”

For these clients, a single Hetzner CCX13 (2 vCPU, 8GB) runs Coolify plus a small constellation of side services for around €17/month, or about €35-50 if you size up to a CCX23 with 16GB and a separate backup volume. We’ve helped clients move from a $1,200/month Heroku setup to a roughly €50/month Coolify setup with no functional regression. Their database backups land in S3-compatible Hetzner Object Storage, and their Slack alerts come from Coolify’s built-in notifier.

When Coolify hurts: at scale beyond a single beefy host, the multi-server story is workable but more involved. If you need genuine multi-region or zero-downtime database migrations across replicas, you’ve outgrown Coolify and you should know it.

When We Pick Kamal

We pick Kamal when:

• The client is on Rails (8 or otherwise) and doesn’t want a UI sitting between them and their deployment.
• The team is small, technical, and would rather understand five lines of YAML than poke around a dashboard.
• The application is essentially one service plus its database and a cache, sometimes with a worker process attached.
• The client has existing infrastructure intuition and wants to keep things minimal.

For these projects, Kamal on a single Hetzner CCX13 (or two, for HA) gives you:

• One YAML file you can read in a minute.
• Zero-downtime deploys via kamal-proxy connection draining and request pausing.
• SSL that just works via Let’s Encrypt.
• Secrets management via 1Password CLI integration (or Bitwarden, AWS Secrets Manager, GCP Secret Manager, Doppler).
• Health checks, log streaming, and remote command execution as first-class commands.

Total cost: €15-30/month for the smallest 2 vCPU / 8GB box, depending on whether you take an HA pair. Total deployment time after the initial setup: 30-90 seconds for a typical Rails app.

When Kamal hurts: if you have many services, the YAML-per-service approach gets repetitive. If your team includes non-developers who need to deploy, the lack of a UI bites. If you need Heroku-style preview environments per PR out of the box, you’ll have to script it.

When We Pick Cloud Run

We pick Cloud Run when:

• The application is bursty: long idle periods punctuated by traffic spikes.
• You need autoscaling to zero (the cost difference matters for early-stage products with intermittent usage).
• The team is already in GCP for other reasons (BigQuery, Vertex AI, Pub/Sub).
• You want managed certificates, managed load balancing, and managed compute without thinking about any of it.
• Compliance requires logs and audit trails at cloud-provider quality.

For these clients, Cloud Run + Cloud SQL Postgres + Cloud Tasks for background work is a complete production stack with effectively zero ops overhead. Pricing for an early-stage product is often less than €20/month and scales linearly with traffic.

When Cloud Run hurts: cold starts on Gen1 land in the 200ms-2s range depending on image size and memory, while Gen2 (microVM execution environment) trades a bit more cold-start latency for better sustained CPU and full Linux compatibility. Startup CPU boost and min-instances=1 are the standard mitigations if cold starts hurt your API.

You can’t run long-running background jobs that exceed the request timeout, and you can’t keep persistent in-memory state. You’re locked into Google’s pricing model, and at sustained high traffic, a Hetzner box with Kamal is dramatically cheaper.

What We Actually Ship

A typical decision tree for new client engagements:

• Single Rails or Django app, small team, EU data, low ops appetite: Kamal on Hetzner.
• Multi-service stack, mixed languages, founder wants a dashboard: Coolify on Hetzner.
• Bursty traffic, GCP-heavy stack, compliance-driven: Cloud Run + Cloud SQL.
• Already-large engineering team with platform engineers: usually a managed Kubernetes service, but only because they specifically asked for it.

We default to Kamal because most B2B SaaS clients we work with are running one application, not a constellation. When that changes, we promote them to Coolify rather than the other way around. The tools were designed for different team shapes and we try to match the tool to the shape, not bend the team into the tool.

We’ve covered the broader operational picture in DevOps for SMBs that don’t have a platform team, and the deployment pipeline that feeds these targets in CI/CD pipelines explained.

The pattern across all three tools is the same: Kubernetes-grade complexity for the apps that genuinely need it, simpler tools for the apps that don’t. Most B2B SaaS in 2026 doesn’t need it.

The infrastructure question that actually matters is rarely “which deployment tool.” It’s “what’s the smallest thing that gets us into production safely, with a path forward we won’t regret in eighteen months?” Pick the smallest fit. Move when you outgrow it.

That’s been the playbook for ten years. Coolify, Kamal, and Cloud Run just made it cheaper to follow without paying the Heroku tax.

Picking a deployment story for a new project, or untangling an over-engineered cloud setup that’s burning budget? Let’s talk. We’ll look at your actual traffic, team, and constraints, and tell you honestly which of these three (or none of them) fits.