Docs
Open Babbit

Concepts

Tiers, releases and hosting

Babbit hosts the code it writes. A release reaches production only after preprod has run it, and the same build moves from preprod to prod. This page covers the tiers, releases, and what you can and can't control.

Babbit runs your product

You own your product's spec. Babbit owns everything else needed to run it: the code, the repositories, deploys, databases and migrations, secrets, scaling and the record of what happened. You don't pick a cloud, write infrastructure files, or keep a deploy pipeline.

Babbit infers what your product needs from its code. A table in the code means a database; a call to an outside service means a connector with its key or sign-in. When the code needs something only you can give, such as an API key, the change asks for it at a gate.

The three tiers

Code runs in three places, called tiers:

TierWhat it isWhat runs there
devThe workspaces a change runs in, each with its own throwaway database.Babbit runs each scenario's test here, in a workspace apart from the one that wrote the code.
preprodA release cut from main, running like production.Smoke scenarios, then a replay of last week's prod traffic.
prodYour live product.Only a release that preprod has run.
The three tiers Dev is the change's own workspace, where Verify runs its tests. A landed change is cut into a release that deploys to preprod, where smoke scenarios run and recorded prod traffic is replayed. Only the release preprod ran moves to prod, after its smoke scenarios pass; a failure at either tier rolls the release back. devpreprodprod The change's workspaceAn isolated copy of your code.Verify runs each scenario'stest here. A release, cut from mainSmoke scenarios run, thenlast week's prod traffic isreplayed against it. The same releaseOnly what preprod ran.Smoke scenarios run againbefore it counts as shipped. landgate A failed smoke run or a broken replay rolls every service of the release back.
A release moves forward only on evidence. A failure at preprod or prod rolls the whole release back.

Every feature shows three tier lights, one per tier, read from the commit each tier actually runs, so the feature list shows what each tier is running.

What a release is

A release is one commit of main for each repository, and every change in it. When you click Merge & release on a change, Babbit lands it and cuts a release. Each service's image is built once, and the same build moves from preprod to prod, so production runs exactly what preprod tested.

How a release moves

  1. Cut. The release records a commit per repository and deploys to preprod.
  2. Preprod. The tier's smoke scenarios run against the deployed release. A failure rolls the release back.
  3. Replay. Babbit replays last week's prod traffic and MCP calls against preprod. Everything the requests did inside your product runs again. Everything they asked of the outside world, such as a payment or a model's answer, gets the answer prod recorded, so the replay never touches anything live.
  4. Prod. A clean replay deploys the same release to production, where the smoke scenarios run again. The release is shipped only when they pass.

What stops a release

EventResult
A smoke scenario fails on preprod or prod.Every service of the release rolls back to the previous version, and the change is blocked.
The replay finds a contract broken, or an answer worse than prod's.The release rolls back.
The replay can't cover a call because prod recorded no answer for it.The release is held until someone allowed to promote to production approves it.
A newer release is cut first.The older release is superseded.

The replay proves that every boundary in your product keeps its contract with the values prod saw. Whether the product did the right thing is for the smoke scenarios to prove.

Where your product is served

Babbit serves each project at an address of its own:

TierAddress
prod<project>.on.babbit.dev
preprod<project>.preview.babbit.dev

Preprod rests between releases, so it isn't running, or costing anything, when there's nothing to test.

Hosting budget

Each project has a monthly hosting budget, in US dollars. It is the only figure Babbit shows in dollars; agent work is measured in tokens. An owner sets it in Project settings.

When a project goes over its budget, Babbit stops its preprod and refuses new deploys until the budget is raised or the month turns. Production keeps running.

Database changes

Migrations run when the new version of a service starts. The deploy step itself never connects to your database. Data comes back from a restore point, never from reverting code, which is why Babbit treats destructive database changes separately: a change that drops a column must ship after the change that stops using it.

Roll back

A failed release rolls back on its own. A release that passed but broke something is undone by reverting its change, which is a new change with its own release. See Undo a release that passed.