# Keel vs Heroku

Keel offers a Heroku-like workflow on AWS resources in your own account. Both support buildpacks, release commands, process types, config vars, and command-line deployments; the main differences are infrastructure ownership and pricing.

## Keep your workflow

**Build it your way.** Bring a Dockerfile and Keel builds that. Don't have one and it uses Cloud Native Buildpacks instead, so asset precompilation and dependency detection work the way they do today.

**The same one-command deploy.** `keel deploy` builds the image, runs your migrations, and rolls out every service. `keel rollback` puts it back in seconds.

**The same release step.** Migrations run before anyone sees the new version. If they fail, the deploy stops and your current version keeps serving.

**The same git-driven deploy.** Every deploy is one specific commit, built from the repo you already push to.

## Command for command

| Heroku | Keel |
|---|---|
| `git push heroku main` | `keel deploy` |
| `heroku ps` | `keel ps` |
| `heroku ps:scale web=3` | `keel scale web 3` |
| Autoscaling — dashboard only, Performance tier and up | `keel autoscale set web --min 2 --max 10 --cpu 60` |
| `heroku logs --tail` | `keel logs -f` |
| `heroku run rake db:migrate` | `keel run -- rake db:migrate` |
| `heroku run bash` | `keel run -i -- bash` |
| `heroku config:set KEY=value` | `keel config set KEY=value` |
| `heroku releases` | `keel history` |
| `heroku rollback` | `keel rollback` |
| `heroku domains:add` | `keel domains add` |
| `heroku addons:create heroku-postgresql` | `keel services add database` |
| Heroku Scheduler | `type: scheduled` with a cron |
| `heroku pg:psql` | `psql "$(keel db url)"` |

## Own the infrastructure

**Your data stays in your account.** Databases run in RDS inside your VPC, and logs remain in CloudWatch. Keel has no hosted control plane in the data path.

**Existing AWS resources are close at hand.** Bind resources such as S3 buckets or peered networks with scoped IAM and private networking where available.

**AWS-native isolation.** Keel supports private subnets, a security group per service, managed WAF rules, and least-privilege IAM task roles.

**Independent resource sizing.** Set CPU and memory for each service instead of choosing a predefined dyno size.

## Pay AWS, not a platform

Keel does not add a usage margin or seat fee; you pay AWS directly.

- **AWS credits and enterprise agreements apply** to the resources Keel creates.
- **Savings Plans can reduce eligible compute costs** for steady workloads.

Price your own config before you build it:

```bash
keel cost              # monthly baseline, from keel.yml alone — no credentials needed
keel cost --all        # every environment
```

`keel cost budget --email you@example.com` then sets an AWS Budget with a forecast alert. [More on cost →](../guide/cost)

## See every deploy

Keel checks the working tree, branch, remote commit, and GitHub connection before building. During deployment, the dashboard shows build status and ECS rollout progress. Afterwards, use `keel history` to review releases and `keel rollback` to restore an earlier task definition. [More on the dashboard →](../guide/dashboard)

## Moving across

| Heroku | Keel |
|---|---|
| `Procfile` process types | `services:` with `command` |
| Release phase | `release:` |
| Config vars | `keel config set` — stored in SSM, injected into tasks |
| Postgres / Redis add-ons | `keel services add database` / `cache` |
| Other add-ons | `keel resources add` for S3, SQS, SNS |
| Custom domains | `keel domains add` — Route 53 + ACM |
| Your data | Dump from Heroku Postgres, restore into RDS |

Most apps leaving Heroku look like [Deploying Rails](../deploying-rails): a web process, a Sidekiq worker, migrations in a release command.

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