Remote ComposeTake any docker-compose.yml and put it on AWS
Your compose file is the topology. rc ships it to a disposable EC2 box with Claude pre-authenticated inside — or renders it into a clean ECS terraform module you own. One tool, two flavors.
Two flavors of one tool
Same insight, two surfaces. Compose is already the spec for "how my services fit together." For dev, rc ships that spec to an EC2 box and starts an agent inside. For production, it renders the same spec to ECS terraform you own.
$ rc dev up alice \
--repo https://github.com/owner/myapp \
--compose docker-compose.yml \
--gh-token "$(gh auth token)" \
--skip-permissions
$ rc dev attach alice
# you're in. tmux, claude code already logged in.
$ rc dev destroy alice
# gone.One box per agent or per branch. Multi-repo deploys, env-file shipping, gh/bd pre-installed, shared SSH key lifecycle all built in.
$ rc up --from-compose docker-compose.yml
# scaffolds rc.yml, applies terraform,
# builds + pushes images, rolls services,
# pushes secrets to AWS Secrets Manager.
$ rc deploy # ongoing deploys
$ rc lifecycle migrate
$ rc db push dump.sql
$ rc status
# the terraform/ dir is yours.
$ cd terraform && terraform apply # works without rc.Declarative + idempotent. Re-running rc deploy with no changes prints no changes — infrastructure matches config.
Why compose is the topology
Most deploy tooling makes you choose: cloud-specific knobs (ECS task defs, k8s manifests, Helm), opinionated black-box PaaS (Heroku, Fly, Render), or hand-rolled terraform (500 lines per service). rc takes the other bet.
Write your compose file once. rc renders it to either an EC2 dev box or to ECS terraform — your choice, same source.
rc deploy emits a clean terraform module to terraform/. Drop the tool, run terraform apply — your infra keeps working.
Every verb is safe to re-run. rc up, rc deploy, rc destroy — all converge on the desired state, no surprises.
From compose to AWS in four steps
Bootstrapping a fresh machine? Run bash scripts/bootstrap-from-zero.sh from the repo first — it installs terraform, creates a venv, and verifies rc doctor is all-green.
# 1. Install (ECS provider — k8s on roadmap)
$ pip install -e ".[ecs]"
# 2. In your app repo, alongside docker-compose.yml
$ rc init --from-compose docker-compose.yml # scaffold rc.yml
$ $EDITOR rc.yml # tweak cpu/memory/health
# 3. Configure cloud creds (ECS example)
$ export AWS_PROFILE=myprofile
# 4. One-shot: scaffold (if missing) → deploy → secrets → ALB URL
$ rc up --from-compose docker-compose.yml
# Or step through manually:
$ rc plan # show what terraform would create
$ rc deploy # build images, terraform apply, force-roll
$ rc secrets push # upload .env files into Secrets Manager
$ rc lifecycle migrate # run a named hook in a live container
$ rc status # ECS service health table
$ rc exec django -- /bin/bash # interactive shell
$ rc destroy --yes # tear it all downWhat rc gives you
Fargate or EC2 launch types. ALB-fronted, Cloud Map service discovery, Container Insights, EFS for stateful services.
.env files become AWS Secrets Manager JSON blobs. The provider emits one task-def secrets[] entry per key so each value arrives as its own env var.
Build via CodeBuild inside your AWS region — no GitHub Actions image push, no Docker Hub 429s, no slow uploads from a remote runner.
Named hooks (migrate, collectstatic, …) run in live containers as one-off ECS tasks. auto_on_deploy wires them into the deploy flow.
rc dev up brings up a full EC2 environment in ~5 minutes with Claude Code pre-authenticated. Multi-repo + env-file ship out of the box.
Skip terraform entirely and just force-roll services onto fresh images. Safe to use when terraform state has drifted — exactly how StartSimpli's prod deploy runs today.
Stop hand-rolling 500-line terraform modules.
rc is alpha, MIT-licensed, and hand-tested against a real production Django + Celery + Postgres stack. The active branch is portable-deploy.