Keel vs Kubernetes

Kubernetes is a general-purpose orchestration platform with a large ecosystem and broad portability. Keel targets a narrower use case: deploying common web application components to managed AWS services without operating a Kubernetes cluster.

Same job, less work

What you want	Kubernetes	Keel
Three copies of a web app	Deployment → ReplicaSet → Pods, requests, limits, three kinds of probe	type: web, cpu, memory, health_check
HTTPS on your own domain	Service + Ingress + an ingress controller + cert-manager + external-dns + issuers	domain: — load balancer, auto-renewing ACM certificate, DNS records, and HTTP→HTTPS redirect
Scale on CPU	metrics-server + HPA + Karpenter	autoscaling: { min, max, target_cpu }
A background worker	A second Deployment, no Service, plus a PodDisruptionBudget	type: worker
A nightly job	CronJob, concurrencyPolicy, backoffLimit	type: scheduled
A Postgres database	An operator to run, or wire up RDS yourself	database: { engine: postgres }
Migrate before traffic shifts	An init container or Job, plus a Helm hook	release:
Let the app read a bucket	OIDC provider, ServiceAccount annotation, trust policy, IAM role	bindings:
Secrets from AWS	External Secrets Operator, SecretStores, sync failures	keel config set
Logs and metrics	Prometheus, Grafana, Fluent Bit	keel logs, keel ps, built-in dashboard
Roll back a bad release	helm rollback, or an Argo sync to a past revision	keel rollback
Know what it costs	Kubecost, or a spreadsheet	keel cost
Keep it all running	Control plane, add-on, and node upgrades, several times a year	Nothing to upgrade

The whole config

name: store
region: us-east-1

pipeline:
  source: github
  repo: acme/store

services:
  web:
    type: web
    port: 3000
    health_check: { path: /up }
    cpu: 512
    memory: 1024
    autoscaling: { min: 2, max: 10, target_cpu: 60 }
  worker:
    type: worker
    command: ["worker"]
    cpu: 256
    memory: 512

database:
  engine: postgres
  version: "16"
  instance: db.t4g.small

release:
  command: ["bundle", "exec", "rails", "db:migrate"]

keel up provisions the infrastructure and keel deploy releases the application. There is no Kubernetes control plane or add-on stack to operate.

Control-plane cost

An EKS cluster carries an hourly control-plane charge even when no workloads are running. ECS has no separate cluster fee, though the Fargate tasks and other AWS resources still incur charges.

When Kubernetes is the better fit

Choose Kubernetes when you need its portability, custom controllers, scheduling controls, or ecosystem. Choose Keel when the standard AWS application stack covers your needs and you want a smaller operational surface.

Get started → · Back to comparisons