Hosted pods

On hosted options, each organization's brain runs on its own dedicated GPU pod that bRRAIn provisions. The pod runs the same installer a customer host runs, under a supervisor loop instead of systemd. The vault lives on a separate network volume attached to the pod. That separation, pod versus volume, explains the lifecycle below.

Provisioning

On your organization's provisioning page in app.brrain.io, Start Provisioning allocates the pod, boots it, exposes an HTTPS URL and polls until the pod is running. When it finishes, the page shows the Brain URL with a Copy button. Paste it into Claude Desktop, VS Code, the browser extension and mobile clients.

After provisioning, check:

1. The installed version on the page. If an upgrade is offered, apply it before go-live.
2. https://<brain URL>/version and /healthz respond.
3. The console at console.brrain.io shows the organization, and its Zones and Status pages are healthy.

Lifecycle controls

Each control's confirmation names exactly what it destroys.

| Control | Pod | Vault volume | What you lose | |---|---|---|---| | Stop Pod / Resume Pod | Paused / resumed | Kept | Nothing. Storage is still billed while paused. | | Upgrade to X | Same pod, upgraded in place | Kept | About a minute of restart. Same URL. | | Kill Pod, Keep Storage | Terminated | Kept | In-pod state such as ontology data, policies, MCP configuration and the audit ring buffer. The vault is preserved. | | Set Up New Brain on Existing Vault | New pod | Reattached | Gives you a new URL over the same vault. | | Kill Storage | Terminated if running | Permanently destroyed | All vault data. Cannot be undone. | | Kill Everything | Destroyed | Destroyed | Everything bRRAIn-managed on the license. The license remains. |

Recreating a pod changes its URL. The vault survives; the address does not. Every client configured with the old URL stops working until it is repointed. Prefer an in-place upgrade to a recreate.

Upgrading in place

When a newer release is available, the page shows Installed and Available versions and an Upgrade to X button. The brain downloads the new release, verifies it, swaps it inside the same pod and restarts in about a minute. Pod, URL, vault, installed extensions, MCP configuration and links all stay. If a pod is too old to upgrade in place, nothing is changed and the page tells you what to do.

Extensions are updated separately, with Update in the console. The brain uses Upgrade.

Automatic rollback

The pod's supervisor watches for a bad release. If the brain fails three times rapidly, each failure within 60 seconds of the previous one, it rolls back to the previous artifact (brrain upgrade -rollback) and starts that. A brain that has run cleanly for a while and then fails once restarts normally. Customer-run hosts under systemd do not roll back automatically; there, you decide (see Updates & releases).