ebman

io.github.tombaldwinPublished by GitHub account tombaldwinv0.49.0Updated Nov 7, 2026

MCP server for AWS Elastic Beanstalk: read the fleet; --allow-writes adds two-phase writes.

Overview

AI-generated overview

MCP server that lets an assistant inspect an AWS Elastic Beanstalk fleet and, when enabled, run confirmation-gated deploys and other writes.

What you can do
  • List and inspect environments, option settings, events, versions and cost
  • Pull triage bundles for unhealthy environments, recent logs, lint and drift checks
  • Inspect worker queues and dead-letter queues
  • Run two-phase writes such as deploy, restart, rebuild, terminate, set option and DLQ resend/delete/purge, where a plan is returned and a separate confirm step dispatches it
  • Declare a fleet-wide deploy freeze
When to use it
Useful when you operate Elastic Beanstalk environments and want an agent to answer questions about fleet health, recent events, logs and configuration drift without shelling out to the AWS CLI. Writes are only worth enabling for clients that can show you a confirmation dialog.
Requirements
Runs as a local process started with the ebman mcp serve subcommand, installed via Homebrew, Cargo or a pre-built binary on macOS or Linux. Needs AWS credentials through the standard chain, configured with AWS_PROFILE and AWS_REGION or the usual AWS config files and instance role. Network access to AWS is required.
Before you install
Write tools can deploy, restart, rebuild, terminate environments and resend, delete or purge queue messages; they are gated by a confirmation step, but the server cannot tell whether your client really asks you, so prefer read-only mode or a narrow allow-list of write tools. The server can also declare a fleet-wide freeze. AWS credentials and account access are used for every call, and actions are logged to a local audit file.

Installation

In SourceWeft

  1. Open ebman in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

ebman

[crates.io] [downloads] [CI] [license] [homebrew] [by Polymorphism]

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

[ebman demo — filter → :why → drill into Detail/Instances → embedded SSM session]

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):

bash
brew install tombaldwin/tap/ebman

Cargo:

bash
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

bash
ebman                                  # launch the TUIebman --read-only                      # disable all write surfaces (audit-friendly)ebman --demo                           # synthetic fleet (no AWS calls) — for screenshots / VHSebman --versionebman --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: 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: 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 <line-id> 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 "<cmd>" 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, 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 (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:

ToolWhat it's good atWhere it falls short for daily EB triage
AWS ConsoleApproachable, complete UI surface.Page loads, eventually-consistent state, 5 tabs to triage one env. Fine for occasional ops, painful at 3am.
eb CLIA single project's deploy flow (eb deploy, eb logs).No multi-env view, no live drill-down, no diff between envs, no SQS DLQ workflow.
aws elasticbeanstalkRaw API access, scriptable.You build the workflow out of --query / jq pipelines yourself. No live updates, no triage view.
k9s + EKSThe pattern this tool is modelled on.Doesn't exist for Elastic Beanstalk.

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

Source: README.md at commit 6e11e3a

Tools

0
SourceWeft started this package once in an isolated sandbox, without credentials, to list its tools. That failed: the package type cannot run in the sandbox.

Version history

17
  1. v0.49.0LatestNov 7, 2026
  2. v0.48.0Oct 29, 2026
  3. v0.47.1Oct 24, 2026
  4. v0.46.2Oct 23, 2026
  5. v0.46.0Oct 22, 2026
  6. v0.45.2Sep 30, 2026
  7. v0.45.1Sep 30, 2026
  8. v0.45.0Sep 26, 2026
  9. v0.44.0Sep 22, 2026
  10. v0.43.0Sep 22, 2026
  11. v0.42.0Sep 20, 2026
  12. v0.41.0Sep 19, 2026
  13. v0.40.0Sep 19, 2026
  14. v0.39.1Sep 18, 2026
  15. v0.39.0Sep 18, 2026
  16. v0.38.0Sep 17, 2026
  17. v0.37.0Sep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts