ebman

ebman

A k9s-style TUI for AWS Elastic Beanstalk. Triage red envs, stream logs, edit option settings, deploy new versions — all from the keyboard. If you've used k9s with Kubernetes, the muscle memory carries: : for commands, / to filter, Enter to drill in, ? for context-aware help.

Install · Quickstart · Triage workflow · Highlights · Why ebman? · Docs

Captured from ebman --demo, the synthetic-fleet mode that ships with the binary. Regenerate the gif with vhs demo.tape after a code change.

Install

Homebrew (macOS / Linux):

brew install tombaldwin/tap/ebman

Cargo:

cargo install ebman

Pre-built binary: download the tarball for your platform from the GitHub Releases page, verify the *.sha256 next to it, extract, and put ebman on your PATH.

Tested on Rust 1.94.1+ (the AWS SDK sets the floor). macOS (Apple Silicon + Intel) and Linux x86_64. AWS SDK uses the standard credentials chain (AWS_PROFILE / AWS_REGION env, ~/.aws/credentials, instance role, etc.).

For the prettier glyph set (Powerline pill chain, Nerd Font tab icons), see docs/fonts.md. The default icons = "unicode" works fine in any terminal.

Quickstart

ebman                                  # launch the TUI

ebman --read-only # disable all write surfaces (audit-friendly) ebman --demo # synthetic fleet (no AWS calls) — for screenshots / VHS ebman --version ebman --help

Once running, press ? for a per-context keymap (Detail, DLQ, Action menu, Saved-configs overlay all have scoped help).

Triage workflow

Production env goes red at 3am. From your terminal:

1. ebman — launch; prod-api shows up tinted red in the table
2. /prod-api ↵ — jump to it
3. ! — open :why: the console's health causes / recent events / alarms / instance health / last deploys, all in one overlay
4. :diff prod-api staging-api — confirm staging is still on the previous version
5. :rollback — redeploy the last-known-good version label, with a 5-second undo window
6. Action + outcome land in ~/.cache/ebman/audit.log

Five keystrokes to triage, one command to fix. The AWS-console alternative is a minimum of five page-loads, two tabs, and zero audit trail.

Built for operators who triage EB envs daily and don't want the AWS console round-trip — or the eb deploy ; aws elasticbeanstalk describe-events --max-items 50 | jq ... shell-pipeline every time something goes red.

Highlights

• Live env table with sort / filter / group-by-app / health sparkline / severity tints / mouse support.
• Per-env drill-down — tabs for Health / Events / Instances / Metrics / Queue / Logs / Config / App.
• Your own metrics — the App tab shows an env's CloudWatch metrics, RDS / ElastiCache rows and top log errors from app.ENV.* in config.toml; with no config it shows what discovery found, and e edits the config in a form, no restart needed.
• Red-env triage — :why opens a one-screen diagnostic: the causes behind the console's banner and the request mix, then recent events + alarms + instance health + last deploys, with a DLQ peek for Worker envs.
• Incident mode — :incident START "headline" freezes deploys fleet-wide, pins a header banner with a running clock, and audit-logs the window; ebman freeze declares a freeze no session owns, holding until ebman thaw; :event-tail streams EB events across every env in one overlay; ebman audit replay re-runs an audited action for post-incident review.
• Honest health — envs with alarms in ALARM, DLQs with messages, or stale platforms surface on the row itself, not behind a tab.
• Forensics — :diff env-A env-B for option-setting deltas, :lineage for the deploy timeline, :alarm-history NAME for CW state transitions, :config-diff-local against a local EB CLI saved config.
• Daily-driver writes — env vars, tags, deploys (label / local zip / S3, with --preview), saved configs, CW alarms CRUD, ALB scheme, instance type, capacity, deployment policy, plus a generic :set-option escape hatch.
• Worker / SQS — DLQ viewer with resend, typed-name purge, bulk delete, peek-and-tail.
• SSM — :ssh i-abc opens an embedded session; :ssm-run " " fans a shell command across the env's instances.
• Multi-account / multi-region — :region all parallel queries (every read and write goes to the row's own region; NAME@REGION picks one of two same-named envs), :account NAME via sts:AssumeRole, :find-env / :org-health walk every ~/.aws profile + configured account.
• Bulk ops — space multi-selects, then :batch-* fans out in parallel with audit + pending-pill rows.
• Safety + audit — --read-only flag, typed-name confirms, per-env / per-account read-only pins, full audit log at ~/.cache/ebman/audit.log.
• Headless / scriptable — --control-socket PATH, ebman envs --json, ebman action rebuild --env NAME, ebman ctl screen / state / cmd <:cmd>.
• Agent-native (MCP) — ebman mcp serve exposes the read surface (envs, worker queues, why triage bundles, recent logs, lint, drift, option settings, events, managed updates, versions, cost) as MCP tools, so Claude Code or any MCP client can query your fleet first-class instead of shelling out and re-parsing. Two-phase writes — deploy / restart / rebuild / terminate / set_option / dlq_resend / dlq_delete / dlq_purge / dlq_redrive / apply_managed_action / rollback / abort_update / swap_cnames / scale (the tool returns a plan, then confirm_action dispatches) — are available when your client can put a question to you: every confirmation becomes a dialog naming the action, what it forecloses, and the identity it would use, and nothing dispatches unless the confirmation is approved. (ebman cannot tell you answering from a client that answers for itself — see docs/safety-and-privacy.md — so on a headless or scripted client, prefer --read-only or a narrow --allow-writes.) Clients that cannot be asked need --allow-writes, or --allow-writes=dlq_resend,dlq_delete to grant only some; --read-only refuses writes on that server outright. Any server, a read-only one included, lets an agent declare a fleet freeze (freeze_fleet), since that only takes writes away; lifting it stays with you (ebman thaw). All of it honours the same safety pins, read-only, and cross-process incident freeze the TUI uses, and audits every dispatch and every refusal.

Why ebman?

You probably already have one of these:

ebman is k9s-for-EB: keyboard-driven, drill-down-first, focused on operators who triage red envs daily and want one screen for "what's wrong" and "what changed". The nearest peer in the broader Rust-TUI / k9s-style space is e1s (k9s-for-ECS); ebman is broader on the write surface and adds multi-account fan-out, an audit log, per-env safety pins, and an embedded SSM-session pane.

Documentation

• Keys — normal mode, detail view tabs, DLQ viewer.
• Command reference — every :command grouped by job (navigation, per-env, write, multi-account, bulk).
• Configuration — ~/.config/ebman/config.toml, plugin commands, project-local pinning.
• Fonts — installing a Nerd Font for the Powerline glyph set.
• Headless interface — --control-socket + ebman ctl for scripts / CI; the CLI subcommands; shell completion (ebman completions); and the `ebman mcp serve` MCP server (read tools + confirmation-gated two-phase writes) for Claude Code and other agents — run ebman mcp setup for the exact registration commands.
• Safety, privacy, what's stored locally — read-only mode, audit log, bug-report scrubbing.
• Architecture — module map, how a keystroke becomes an AWS call, and the invariants the compiler doesn't enforce.
• Development — build / test / clippy + distribution notes.
• Contributing — setup, the pre-PR checklist, and what makes a change easy to accept.

License

Dual-licensed under MIT or Apache-2.0. See LICENSE-MIT and LICENSE-APACHE.

---

Built and open-sourced by Polymorphism — enterprise software, cloud & AI. More on the ebman product page.

MCP Registry name: mcp-name: io.github.tombaldwin/ebman