Roadmap

Where Keel is headed. Nothing here is a commitment or a date — it's the shape of what we're exploring, ordered roughly by how excited we are about it. Some entries note what already exists today, so you can tell the new part from the shipped part.

Agentic AI harness

An AI agent that lives inside Keel, speaks fluent AWS, and already knows your app — because it can read your keel.yml, your deploy history, your logs, and your live infrastructure the same way the dashboard does.

What that looks like in practice:

• Plan in plain English. "Add a staging environment in us-west-2 with a smaller database" becomes a proposed keel.yml diff and the exact commands that apply it. Nothing runs until you've seen the plan — the same contract keel up already honors.
• Draft your config for you. Point it at a repo and it reads the code: detects the Rails app and the Sidekiq worker, notices the /up health endpoint, spots the migration step, and writes the keel.yml — services, commands, release hook, secrets list — that the app actually needs.
• Debug a deploy like an operator would. "Why did the 2pm deploy fail?" chases the answer through preflight, CodeBuild logs, ECS stopped-task reasons, and CloudWatch — and comes back with the diagnosis ("the release command timed out mid-migration") and the suggested fix, not a pile of log links.
• Interrogate production. "What changed since yesterday?", "which service is eating the memory?", "find the slow queries" — answered from live state and metrics, in the terminal where you already are.
• Tune scaling from real usage. It watches how your services actually behave and proposes the autoscaling config to match — as a diff you can read, not a setting it silently changes.

The guardrails are the point: the agent proposes, you approve, and every action goes through the same access levels and audit trail as a human running the CLI. Your credentials never leave your machine.

App Library

Keel manifests for pre-built images: point at a curated Docker Hub image — Grafana, Metabase, PostHog, and friends — get a sensible config surface, and run it like any other service. One command from "we should have a Metabase" to a URL.

Plugins

A plugin surface for the workflows that live next to Keel: the first candidate is keel db psql — a tunnel into the VPC that lands you in a psql prompt against the managed database, no bastion setup. (Today keel db url prints the connection string, but the database is in private subnets by design; the interactive route is keel exec.)

Pricing estimator

Estimate monthly spend from what's configured and deployed, per app and environment. Live estimates as you edit keel.yml, plus suggested AWS budgets with auto-configured spend limits and alerts.

Static sites & CDN

S3-backed static sites as a first-class app type, with CloudFront in front and the same custom-domain + ACM treatment web services get today.

Buildpacks

Apps without a Dockerfile should still deploy: detect the stack and build with buildpacks instead of requiring everyone to write container plumbing.

Internal-only services

Services exposed through an internal load balancer — reachable from the VPC or a VPN rather than the public internet. Today the only routing choice is "public web service" or "no routing at all".

Database performance insights

RDS Performance Insights surfaced in the dashboard: query latency charts, long-running queries, and the "what changed at 2pm" view, without leaving the terminal.

Guided database upgrades

database.version is config today, but "Postgres 16 is going EOL" deserves a guided path: what changes, what downtime looks like, minor-version policy, and a dry run — natively from Keel rather than a config edit and hope.

Read replicas & multi-node databases

multi_az (a failover standby) exists today; readable replicas and reader endpoints for scaling reads do not — yet.

Deployment strategies

Today every deploy is an ECS rolling deployment with a circuit breaker — a bad revision rolls back instead of looping, and the release command gates promotion. Making the strategy configurable — blue/green, canary percentages, bake time — is the roadmap item.

Autoscaling strategies

Target-CPU autoscaling per service (autoscaling: {min, max, target_cpu}) exists today. Planned: recommended strategies out of the box — memory- and request-based targets, scheduled scaling, and suggestions derived from your actual usage.

Cron & scheduled tasks

type: scheduled is accepted by validation today but runs like a worker — the EventBridge wiring behind the name is the roadmap item. (Background jobs already work: type: worker services run continuously with no public exposure.)

EC2-backed capacity

Fargate is the only launch type today. EC2 capacity providers would open up cheaper sustained workloads, GPUs, and spot strategies.