CLI — for pipelines & the lead
$ steer --context stg service deploy -s api -t v1.2.3 -y # scriptable, CI-friendly, no prompts
First-class in CI. Every action is a flag away, deterministic and safe to automate.
Open-source dev tool · CLI + TUI
Platforms like Vercel and Railway made shipping effortless — but they lock you in. Steer brings that same “just ship it” feeling to the cloud account you already own. Set it up once; then anyone on the team deploys, without touching the console.
SERVICES (4) ● api 2/2 v1.4 ● web 3/3 v2.0 ◐ worker 1/2 v1.1 ○ cron 0/1 — IMAGES (3) ▸ api ▸ web ▸ worker DATABASES ···Details Events Logs running 2/2 pending 0 status ACTIVE tag v1.4 [d] deploy [s] scale [z] resize [R] rollback
Two faces, one helm
$ steer --context stg service deploy -s api -t v1.2.3 -y # scriptable, CI-friendly, no prompts
First-class in CI. Every action is a flag away, deterministic and safe to automate.
$ steer tui # run a command with no args → # an interactive picker opens
A persistent dashboard with interactive pickers and an in-TUI context switcher. Ship without knowing AWS underneath.
What it does
Read-only production, confirmations and a preview of what will happen before it happens. Rollback is one command — hard to break things by accident.
Pick services and image tags from live, fuzzy-filtered lists — the tag picker reads your registry, and every deploy is validated against it before it runs. Stuck rollouts are detected, not waited on forever.
The health of everything at a glance in a persistent multi-panel layout — keyboard-driven, mouse-friendly, with live Events and Logs tabs per service. Switch account or cloud from inside the TUI. Inspired by lazydocker / lazygit.
Failures explain what went wrong, why, and what to try next — instead of dumping a raw cloud stack trace on you.
An interactive wizard (steer config init) detects your AWS profiles, lists your real clusters and writes steer.toml for you. Several accounts or environments are just several contexts.
Install via Homebrew, go install or a direct download. One static Go binary — no runtime to manage.
Who it’s for
Configures steer.toml once — accounts, role ARNs, environments, naming conventions.
Deploys, scales and checks status with simple commands and the TUI, without understanding AWS underneath.
Honest scope: a solo dev with nobody to do the one-time setup is better served by a managed PaaS. Steer shines when someone owns the AWS setup and hands the team a safe, simple way to deploy on top of it.
Under the hood
Commands are named by capability (deploy, scale, rollback), not by AWS service. The core talks to capability interfaces, so Azure or GCP can be added later without reworking it — AWS is just the first adapter. The TUI context switcher already lists AWS, GCP and Azure contexts side by side (non-AWS marked not-yet-implemented), so the multi-cloud seam is visible today.
The Bubble Tea UI is split into single-responsibility components (sidebar, panel tabs, action overlay, keymap, styles), each rendering to a deterministic string so it can be unit-tested without a real terminal.
TUI and CLI share the same domain core. The lead scripts deploys in CI (steer --context stg service deploy -s api -t v1.2.3 -y); the team uses the interactive TUI. Neither path forks the logic.
Production is read-only unless explicitly writable; destructive actions require confirmation and show a preview. The guardrails live in the core, so both the CLI and the TUI inherit them.
It’s open source and a work in progress. Take a look, or reach out if you want to talk.