Booster
Delivery control plane — branch hygiene, CI gates, release, publish, deploy, and rollback across the whole fleet.
In the constellation
Booster highlighted in the live map — hover or tap any node to explore.
Why it exists
A real software operation is dozens of repositories and several deploy targets, and the unglamorous work of shipping — pruning branches, running the same checks everywhere, cutting releases, publishing artifacts, deploying, keeping version pins in sync across repos — is scattered across brittle scripts and provider dashboards that all work differently.
Worse, every one of those tools hard-wires you to a specific provider. Switch where you host, release, or deploy and you rewrite your pipeline. The plumbing of shipping software has no single, neutral home.
What Booster is
Booster is a delivery control plane — one clean command surface for the entire producer side of shipping software: branch hygiene, a portable CI gate, releases, publishing, deploys, and cross-repo version propagation, across providers like GitHub, Cloudflare, and Fly.
It’s deliberately provider-neutral: provider names live in one config file, never in the commands. Every verb speaks in neutral nouns — source, store, runtime — so adding a new provider is a single adapter, and switching one never touches the way you ship.
What it does
Portable CI gate
Run your formatting, lint, test, and secret-scan rules as one staged, exit-accurate command that behaves identically on a laptop, in a sandbox, and in the cloud.
Release & publish pipeline
Version bump, changelog, tag, GitHub release, and checksummed artifacts pushed to your distribution channel — the whole pipeline as one verb.
Deploy & cross-repo propagation
Ship a service to its host, and bump a dependency’s version across every repo that consumes it — each change build-and-gate-verified before it lands.
Fleet hygiene & catalog
Prune merged branches and stale clones across the whole fleet, and keep a single catalog of every repo, its provider facts, and its plan limits.
The line between judgment and machinery
AccelMars draws one hard line through every product: what an AI decides, and what runs deterministically. Booster sits on the boundary — and keeps the two honest.
Where AI judges (the closed overlay)
- Whether a flagged secret is a real leak
- When a dead repo is safe to retire
- Diagnosing why a release or cross-repo bump failed
What stays deterministic (the open core)
- The CI gate, releases, publishing, and deploys
- Branch hygiene and the fleet catalog
- Provider-neutral routing of every verb
The whole mechanical pipeline runs on its own — the open core is complete without any AI. A closed judgment layer sits on top for the few calls a human would otherwise have to make, and falls back safely when it’s not present.
Live in production — shipping the entire AccelMars fleet today, from CI gate through release, publish, deploy, and rollback.
Open core (Apache-2.0): the full mechanical control plane is open and works unmodified for any team. The AI-judgment overlay is the proprietary layer on top.