Operate a self-hosted instance

What this is

Every deployment has one reserved org called Backstage. It's where the deployment itself is run. Every admin of Backstage is a platform operator, with every operator permission. Operators see two extra tabs in Settings: Instance keys and Fleet.

Backstage never appears in the org chooser, and customer admins never see its tabs.

Become the first operator

You name the first operator during the install, when you run the database step:

migrate-db.sh --stack-name <name> --admin-email <operator email>

That provisions the address as a Backstage admin. It's safe to run again. On an upgrade, leave --admin-email out: a different address makes a second operator.

The operator account has no password. To sign in:

1. Go straight to https://<your host>/backstage. The org chooser never offers it.
2. Sign in with an emailed sign-in link (ask for a reset link, then follow it, no password needed), or with Google if your deployment has it turned on.

Arm the instance key

An instance key is one model provider key for the whole deployment. Any org that hasn't set a key of its own runs on it, and so do the built-in agents (Orca and the Agent Builder). An org's own key always wins.

1. In Backstage, open Settings → Instance keys.
2. Click Provision for a provider, such as Anthropic, OpenAI or Amazon Bedrock.
3. Paste the Provider key and click Provision. For Bedrock there's no key: you pick the AWS region and the Model, and the deployment's own AWS role is the credential.

Rotate replaces the key in one step, with no per-org copies to chase. Remove takes effect immediately: every org running on it stops working at its next message unless it has a key of its own.

The panel recommends Opus 4.6 for the built-in agents. Other models may work less well for them.

Create the first organization

1. In Backstage, open Settings → Fleet and click New organization.
2. Enter the Organization name, an optional Slug (the address the org is reached at), and the First admin's email.
3. Click Create. That person becomes the org's first admin and gets an invite by email.

The org's data residency region is fixed by the deployment and can't be chosen. From there, the org's admin sets up the workspace.

Manage organizations in Fleet

Settings → Fleet lists every org on the deployment, with its status, region and creation date. Every action you take on an org is recorded in that org's own audit trail, naming you as a platform operator. The customer can see what you did.

Backstage itself can't be suspended or purged.

Admission limits

Runs started through the public API with an org's API keys are bounded. Unless you set other limits, an org can have at most 5 such runs in flight and start 60 new conversations per 60 seconds. There's no screen for this. An operator sets limits from the admin MCP server with the fleet tool's set_limits verb, per org, agent or function. A limit set to empty turns that bound off.

The spend ceiling

Interactive agent conversations (console chat and embedded agents) have a spend backstop per signed-in identity: $25 of model spend in a rolling hour by default. The service reads it from SPEND_CEILING_USD and SPEND_WINDOW_MS. The AWS template sets neither, so the defaults apply. The ceiling is counted approximately, per server. See See and control what it costs for what it covers.

What can go wrong

• Nobody can sign in after the install. --admin-email was left out, so Backstage has no members. Run migrate-db.sh again with it.
• Agents fail with runtime_not_configured. The org has no key of its own and the instance key isn't armed. Arm it in Settings → Instance keys, or have the org add its own in Settings → Model keys.
• You can't see Fleet or Instance keys. You're signed in to a customer org, or you aren't a Backstage admin. Go to /backstage.
• You suspended an org and its running work stopped. That's what suspending does. Restoring doesn't restart it.
• You need a different region for a new org. The region is stamped on the deployment at first install and can't change.