# Keel vs Kamal

Kamal deploys containers to servers you operate over SSH. Keel deploys to managed AWS services in your account. The tradeoff is direct server control with Kamal versus less host-level maintenance with Keel.

## What AWS runs for you

**A managed database.** Keel provisions RDS with automated backups, optional Multi-AZ failover, managed patching, and an AWS-generated master password in Secrets Manager. With Kamal accessories, your team is responsible for the database container and its recovery plan.

**No application hosts to patch.** Fargate manages the underlying hosts. `keel exec` uses ECS Exec with IAM authorization, so it does not require inbound SSH or key pairs.

**Managed scaling.** `keel scale web 6` changes the desired task count, while autoscaling can follow CPU, memory, or request volume. Capacity is not tied to a manually managed host list.

**AWS-native access controls.** Keel uses private subnets, per-service security groups, IAM roles, MFA, and eight-hour sessions. [More →](../guide/auth)

**Environment isolation.** Each environment has separate state and resources and may use a separate AWS account.

**Costs you know up front.** `keel cost` prices your config with no credentials needed. [More →](../guide/cost)

## What stays the same

- **One config file in the repo** — `config/deploy.yml` becomes `keel.yml`
- **Your Dockerfile** — Keel builds it, or buildpacks if you don't have one
- **One command deploys** — `kamal deploy` becomes `keel deploy`, with a lock, history, and rollback
- **No hosted control plane** — the application and credentials remain in your AWS account

## The short version

Kamal is a good fit when you want direct control of a small set of servers. Keel is designed for teams that prefer managed AWS compute, databases, networking, autoscaling, and IAM without assembling those pieces themselves.

[Get started →](../guide/getting-started) · [Back to comparisons](./)