On AWS already: it reads the account for free, says where the money is going, and names what it could not check. Not there yet: it prices the whole environment before it creates anything, and stops at a ceiling you set. What it writes is plain Terraform that keeps working without Bronco.
Not urgent, but do not defer: CloudTrail is not enabled. 2 more need attention this week; the rest is hygiene. 57 checks ran, in us-east-1, plus the account-wide checks; 1 could not be checked — not counted as passes. WHAT BRONCO FOUND ──────────────────────────────────────────────────────────────────────────────── WHAT YOU PAY SECURITY RELIABILITY $0.0090 / month 50/100 D 100/100 A measured · last 30 days over 26 checks over 12 checks 0 findings · none recoverable 3 findings 0 risks 3 high/critical · 2 auto-fixable nothing found high · CloudTrail is not nothing found enabled security: fixing the one — CloudTrail is not enabled → 60/100 (C) Measured 2026-08-08 → 2026-09-07 UTC · UnblendedCost. AWS forecasts $54.09 (2026-09-07 → 2026-10-01) against almost nothing billed yet — Cost Explorer's data ends about a day back, so anything started today is in the forecast and not in the measurement. WHOSE ────────────────────────────────────────────────────────────────── 5 findings, scored or not yours 3 your decision, or the account's own settings your environments' 0 Bronco built it, the decision is still yours Bronco's own 2 Bronco's decision, not yours 2 findings not scored — by design bronco doctor --why Both grades are the account's — these checks have no per-environment version. COULD NOT BE READ ────────────────────────────────────────────────────── 1 · not counted as passes ? Whether you're paying for oversized servers. Not switched on. It is a Cost Explorer preference, set once on the account that pays the bill; AWS needs about a day of data after that. AWS says: Rightsizing EC2 recommendation is an opt-in only feature. You can enable this feature from the PAYER account’s Cost Explorer Preferences page. Normally it may take up to 24 hours in order to generate your rightsizing recommendations. DO THESE THREE TODAY ───────────────────────────────────────────────────────────────────────────── 1. CloudTrail is not enabled High — this is how accounts get taken over Create a multi-region trail delivering to an S3 bucket. The first copy of management events is free. bronco fix --dry-run free 2. Threat detection is off High — this is how accounts get taken over Enable GuardDuty in this region. It reads the logs the account already produces — no agent, no change to any application. bronco fix --dry-run free 3. IAM user can do anything — bronco-admin High — this is how accounts get taken over Scope it to what this user actually does. For a deploy identity, bronco login --aws creates one with exactly the permissions Bronco needs — no admin key ever passes through the CLI.
Bronco grades the consequence of a finding, not the loudness of a message, and these are the sentences the CLI prints. The orange is the brand's and appears in no finding and no screen.
bronco doctor58 checks on any AWS account, free forever, including one Bronco never touched. What it reads →
bronco forgeA conversation in business terms, priced in full before a single resource exists. What it builds →
bronco deployA release that cannot serve puts the previous one back, with nobody at the keyboard. The release receipt →
bronco watch · driftA monitor inside your own account, and a diff between what is live and what was applied. Growing and pausing →
bronco destroy · sweepA teardown that probes every resource instead of trusting a tag query. Never gated. The teardown screen →
A denied read is a coverage gap, not a pass: an account that denies every read must not score 100. 27 of the 58 checks report what they could read and name what they could not. Which ones, and why →
The scans are read-only by construction. Remediation is a separate, explicit act.
COVERAGE GAP ────────────────────────────────────────── Idle load balancers not checked needs elasticloadbalancing:DescribeLoadBalancers 2 of 58 checks could not run. Nothing below is a statement about what they would have found.
Its own defaults, its own machinery and the leftovers of an environment you tore down are excluded from the grade, and the screen lists each one.
Idleness is measured over fourteen days, stays silent under seven datapoints, and never carries an automatic fix.
The network, database, cache and load balancer a service runs on stay the environment's. The screen names them; the grade stays the account's.
How many availability zones an environment pays to survive is the single biggest choice in it. Bronco asks it as a consequence rather than as an architecture question, and prices all three answers against the environment being planned.
Sign-in is billed per monthly active user and email per message, so neither is folded into the estimate — the conversation says so and leaves them out.
◇ If this goes down for ten minutes ────────────────────────────╮ │ │ │ This decides how many zones your environment pays to │ │ survive, which is the single largest line on the bill. │ │ It is not about how important your app is. │ ├────────────────────────────────────────────────────────────────╯ ? What happens? ● Nothing much I notice, I fix it, life goes on — one zone, a zone failure is an outage until AWS restores it ○ I lose users people leave and some don't come back — two zones for the app, one for the database ○ I lose money there are transactions in flight — two zones for everything, standby database
Review Cloud AWS · us-east-1 Project broncotest1-ags3lk Environment dev Services api api :3000 → apidb, cache worker worker internal → workerdb, cache, jobs Resources apidb (db), workerdb (db), cache (cache), jobs (queue), auth (sign-in), email (SES) Est. cost ~$113/mo Where it goes Shared substrate $35 network, NAT, secrets, keys, logs Database $30 apidb db.t4g.micro · workerdb db.t4g.micro Load balancer $18 one shared across every public service 2 smaller lines $30 compute, cache ▌ Connecting to AWS ✓ AWS account 2715•••3855 (bronco-admin) ? Create this infrastructure in AWS account 2715•••3855? Billing starts now. ▌ Provisioning ✓ Plan ready — 135 to create (7s) Service + ALB ............... 34 CI build ..................... 8 Networking .................. 32 database named ............... 6 Observability ............... 20 cache named .................. 3 Core ........................ 15 Auth ......................... 2 Secrets ..................... 13 Email ........................ 2
Standard HCL with no proprietary wrapper, and the state lives in a hardened bucket in your
account. Every release runs terraform init and terraform validate
against a workspace generated exactly as the build generates it, and a subset through
terraform plan — so the claim that it runs without Bronco is a gate, not a
promise.
When an address has to be confirmed by a human clicking a link in an inbox, Bronco says an alarm that fires reaches nobody until somebody does, rather than reporting success.
┌──────────────────────────────────────────────────────┐ │ │ │ Release receipt · ledger-dev · 2026-09-04 16:22 │ │ │ │ cost, security and reliability, before vs after │ │ │ │ Images 2 services │ │ api sha-9f3c1a → sha-2b77de │ │ worker sha-9f3c1a → sha-2b77de │ │ Cost $91/mo → $103/mo +$12/mo (+13.2%) │ │ estimated │ │ Security 48/100 → 48/100 no new findings │ │ Reliability 95/100 → 95/100 unchanged │ │ Version 1.4.2 │ │ Verdict ✓ kept — no regression │ │ Deploy ✗ worker is not consuming │ │ ledger-dev-jobs │ │ │ │ this receipt does not measure whether the app works │ │ │ └──────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────┐ │ │ │ ✗ Deploy aborted — api is NOT serving │ │ │ │ api has 0 tasks running: requests to it are failing │ │ right now. │ │ api answered nothing at /health — its health check │ │ does not pass, so the load balancer sends it no │ │ traffic — it is not serving. │ │ │ │ Bringing the last working version back now — pass │ │ --no-rollback to keep the failed revision up. │ │ │ └──────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────┐ │ │ │ ✗ api back on the previous release — the new one │ │ did not ship │ │ │ │ api is back on revision 41 (279s). │ │ api answered 200 at /health — it is serving again. │ │ │ │ The migration that ran stays applied; the code │ │ serving now is the previous release. │ │ │ └──────────────────────────────────────────────────────┘
bronco forge --config <file> reads the answers to the build conversation
out of a file, so repeating a decision somebody made on purpose stops being a person typing.
destroy, rollback, restore, run,
db, pause and alerts take --yes and skip
their confirmation.
The gates are the same ones a person gets. An agent running these verbs cannot get past a
spending ceiling, cannot apply a plan nobody approved, and cannot make
bronco evolve accept a plan that deletes something.
On 2026-09-07 a build driven by forge --config ran unattended on a real AWS
account to its first release.
# the design, decided once by a person, kept in the repo bronco forge --config bronco.forge.json # the loop, from then on bronco deploy --env dev bronco rollback --service api --yes bronco run "npx prisma migrate deploy" --env dev --yes # failure is a number, not a paragraph bronco apply --plan plan-4f21 --env prod exit 2 an approval is missing exit 3 the plan is stale — take it again exit 4 a spending ceiling stopped it, or the artefact does not match its hash
bronco deploy has no --yes. Off a terminal it takes the safe branch
of every warning it raises, and provisioning a brand-new service still asks.
Bronco's MCP server is a separate thing and it is read-only: an agent connected
over MCP can diagnose the account and hand you the exact command, and cannot deploy, fix or
destroy anything. ask and chat run inference on your own model access —
your API key, or a model in your own AWS account — so the prompts and the infrastructure never
reach a service of Bronco's, and any write they propose hits the same gates.
That is the correct place for it, and also why a failed migration used to end at the AWS
CLI. bronco run runs one command inside your app — same image, same environment
variables, same secrets, same network — and the exit code you get back is your container's.
bronco db runs SQL against that environment's own database from inside the
environment, and the password never reaches your machine.
Both work in production, where they ask first.
▌ Running in api $ npx prisma migrate status · Starting a task ✓ Task running (0s) 1 migration found in prisma/migrations Following migration have failed: 20260904030000_broken The failed migration(s) were applied but not rolled back. ✓ Command finished — exit code 0, ran inside api in dev. ── production is a confirmation, never a refusal ───── PRODUCTION — this runs inside ledger · prod, against real data. command npx prisma migrate resolve --rolled-back \ 20260904030000_broken as api (api's image, its role, its secrets) ? Run it? (default No)
If you tell Bronco your secrets are already in AWS it does not upload them, and it used to create the variables empty anyway — so the container started with them defined and blank. The deploy now names every declared key that is stored but not injected, before the rollout.
bronco logs asks what you are looking for and searches inside AWS: the last few
minutes, only errors, since the last deploy, the last 24 hours, or free text. In a real run
logs --errors found the cause of a failed deploy in three seconds.
bronco evolve — change a live environmentAdd a service, a database, a cache, a queue or a connection to a running environment, or raise one service's resilience. The preview shows the derived cascade first: a service's criticality propagates to every resource it is wired to.
It adds and scales up, and nothing else. It plans the change and refuses on any delete or replace in that plan, restoring the previous workspace — the gate reads the plan rather than reasoning about what AWS treats as destructive.
bronco replicate — build the next environment from this oneIt carries the design — the services, their criticality, what each is wired to, the named resources — and lets the target re-derive its capacity at its own ceiling. A staging environment derived from dev is not a dev environment with a different name.
It reads the source's saved configuration and never its state, so it cannot disturb a live one, and it never copies data.
In a real run, replicate built a 120-resource staging environment from dev in 11m59s.
bronco pause stops your compute and your database and keeps your data, your
secrets and your URL. It also says what it does not stop — network, cache, NAT
gateway and load balancer, about $45 of a $143 monthly bill on one real staging environment.
bronco adopt brings existing VPCs, databases, services and load balancers under
management — journaled, resumable, and importing an explicit set. adopt undo
hands it all back, and after that no teardown in the account still claims an environment
needs the account-wide controls it no longer has.
AWS keeps answering tag queries with resources it has already deleted, and a teardown runs at exactly the moment that index is most stale. So Bronco probes each one, and the four kinds of leftover get four different sentences — "this is still running" and "I could not check this" used to print identically.
bronco sweep asks it from the other side — what does Bronco own here, read from
AWS tags with no regard for any state file. Its exit code is 2 only when something is both
unaccounted for and still running.
◇ Destroying complete — 19/19 resources (4m 36s) ✓ Log groups — 1 deleted (1s) ✓ 9 resource(s) still report this environment's tags ┌──────────────────────────────────────────────────────┐ │ Result │ │ │ │ ✓ Destroyed — AWS charges stop now, except what │ │ sits in a deletion window. (4m 51s) │ │ │ │ Role permissions ceiling was already here when │ │ Bronco arrived — untouched, $0 a month. │ │ 2 resources sit inside a scheduled-deletion window │ │ — an encryption key or a secret keeps billing until │ │ the window closes, then AWS removes it with no │ │ action from you. bronco sweep lists which. │ │ 9 resources still carry this environment's tags — │ │ often just AWS-side deletion lag; re-check in a few │ │ minutes with bronco sweep. │ └──────────────────────────────────────────────────────┘ Next → bronco sweep · verify nothing costly was left behind ($0)
destroy · rollback · restore · logs ·
outputs · plan · discover · run ·
db · pause · resume · ask, and the
spending brake. A lapsed licence must never trap you with running AWS costs you cannot see or
stop, must never stand between you and your own recovery, and must never silence a safety
question.
evolve and replicate, and the health-gated deploy
along with the release receipt and the automatic rollback that live inside it. Those are the
reasons to stay, and they are the only ones.
Credentials are resolved on your machine by the AWS SDK and never leave it, and the optional monitor Bronco can install runs in your account too.
The first environment takes about ten minutes to build and about seventeen more to ship the first release. A platform-as-a-service reaches a live URL in ninety seconds and always will; building this by hand is weeks of an architect's work.
The daily loop after that no longer costs an outage. A dev deploy used to stop the running container before starting its replacement, measured at 2m43s, 2m23s and 2m24s on three releases; the replacement now passes its health check before the old one goes, measured from outside the stack at zero seconds of downtime, and a deploy that cannot start is refused in 2m03s rather than 7m30s.
Provisioning measured on a real AWS account twice: 9m25s and 17m29s to the first release on 2026-09-04, 9m57s and about 17 minutes on 2026-09-07. The downtime and the abort are in the changelog, the second across 2139 of 2139 probes answered normally.
The environments built in those runs cost between $77 and $143 a month of real AWS, billed by AWS to you with no markup and no cut. The screen you approve is the bill you get, and there is a monthly ceiling on every plan: Bronco warns at 80% and will not build past it without asking.
The estimate was understating a real environment by $26 a month across five lines AWS charges for and the figure did not name: container telemetry, the two public IPv4 addresses every internet-facing load balancer holds at $7.30 a month, the content-delivery distribution, dev's NAT gateway, and stored secrets. All five are named now, and the compute rate that ran 1.9% low rounds up.
Measured on a real AWS account, 2026-09-03: dev environments estimated at ~$98/mo and ~$77/mo on two projects, a staging environment at ~$143/mo. Estimates the CLI prints before it builds.
A platform needs a GitHub login.
The copy that shipped carried 12 of the 58 checks and was two months behind the ones Bronco itself runs. The digest now states how much of the catalogue ran, and a release check fails if any check is missing from what gets installed.
Six findings came from log groups belonging to environments torn down months earlier. On the account measured, reliability went from 77/100 (B) to 100/100 (A) with nothing changed.
Seeing your account is free forever, and that means the whole itemized report rather than a
preview. Your first dev environment is free forever too, and it is real, not a
trial. Having Bronco remove what the report found is the part that costs money.
cost / audit / risk / driftsweep --all-regionsdev environment — forge, deploy, for realplan · outputs · logs · run · dbrollback · restore · pause · resumedestroy — never license-gatedfix and audit --fixwatch on — the monitor, in your own accountadopt run — existing infrastructure, under managementchat — the operator that can build and fixbilling --by tenant — spend per clientaudit --compliance and evidence packsIf you have not already chosen AWS, use one. Nothing on this page is faster or cheaper. Bronco is for the person already on AWS or with no choice: credits that only spend on AWS, a client or a compliance requirement, a platform bill that started to hurt, or an inherited account. For that person the question is what is inside the account they already pay for.
Use one. Some carry more checks than Bronco does, and the good ones cost nothing. A scanner detects, ranks by its own severity labels, and cannot change anything. Bronco's read is free too; the difference is the four stages after it, and findings ranked by money and blast radius with a dollar figure on each.
No. Every write prints a plan first, and nothing applies without an explicit confirmation or a rule you wrote yourself.
Unattended remediation ships switched off. It needs a policy file you write, saying what may be fixed without asking and what must never be touched, and every action it takes is reversible with one command.
The free read, on Node 18 or newer. Leaves nothing behind.
Then the command is bronco.
The package is bronco-cli because bronco on npm belongs to somebody
else. The command you type was never going to change.
bronco activate <license-key>, only past the free tier.