Launch mode
What the setup wizard checks, and how the two modes differ
In this page
The first screen a fresh self-hosted install shows at /setup asks how you plan to run the instance. That answer is the launch mode, and it decides how strictly the pre-flight checks on the next screen are enforced. It changes how a result is reported, never which services run.
Production requires every core system and holds you on the setup screen while one is down. Test flight eases the non-critical ones so a partial stack still gets you through. Both run the same twelve checks against the same services.
%%{init: {"flowchart": {"curve": "linear"}}}%%
flowchart TD
accTitle: One probe result, reported two ways depending on launch mode
accDescr: A non-critical service that is down reads as Failed and holds you on the screen in Production, and as Caution or Optional that never blocks in Test flight.
P["A non-critical service is down"] -->|"Production"| L["Failed, holds you here"]
P -->|"Test flight"| E["Caution or Optional, never blocks"]
The two modes
You pick one on the first setup screen, and Production is selected by default. The choice is not written to .env and nothing reads it later, so it only affects this one run through the wizard.
Production
For an instance that will carry real traffic. Every core system has to answer before you can continue, and a single failed check holds you on the screen until you fix it. The two feature-level services, the agent fixer and the code execution sandbox, still read as a caution rather than a hard stop.
Test flight
For trying Future AGI out locally. The same twelve checks still run and you still see every result, but the non-critical ones are downgraded so a partial stack reads as expected rather than broken. Nothing blocks you from continuing.
What each status means
| Status | Meaning |
|---|---|
| Ready | The service answered |
| Caution | It’s down, but this mode doesn’t require it |
| Failed | It’s down and this mode requires it |
| Optional | It’s down, and this mode doesn’t use it anyway |
| Checking… | The probe hasn’t come back yet |
A service that answers always reads Ready, in both modes. Whether it’s up is a fact about your deployment and never varies by mode, so only the label on a down service changes. Only Failed ever blocks you; the rest are there to be read.
The pre-flight checklist
Twelve rows appear on screen. Ten of them probe a service, each with a three-second timeout, in the order below. The two mode columns show what a down service reads as, and the container column is what to restart when one fails.
| Check | Container | What breaks | Production | Test flight |
|---|---|---|---|---|
| Core application database | postgres | Nothing loads at all | Failed | Failed |
| Tracing data warehouse | clickhouse | Traces, spans and dashboards won’t load | Failed | Failed |
| Cache and session store | redis | Sign-ins, caching and rate limits break | Failed | Caution |
| Websocket connection | rabbitmq | Live updates won’t reach the browser | Failed | Caution |
| Object storage service | minio | Dataset uploads, exports and media fail | Failed | Caution |
| LLM request gateway | agentcc-gateway | Every model call fails | Failed | Failed |
| Async task engine | temporal | Evaluations and scheduled jobs won’t run | Failed | Failed |
| Trace ingestion | fi-collector | Spans sent by the SDK won’t arrive | Failed | Failed |
| Django backend | backend | Not probed, always reads Ready | n/a | n/a |
| React frontend | frontend | Not probed, always reads Ready | n/a | n/a |
| Agent fixer (evals + Error Feed) | serving | Built-in evaluations and guardrails won’t run | Caution | Optional |
| Code execution sandbox | code-executor | Custom code evaluations won’t run | Caution | Optional |
Django backend and React frontend are the two unprobed rows: both are inferred from the page having loaded at all, so they can never come back as anything but Ready.
The results come from GET /api/setup-checks/, which needs no authentication and returns 404 on anything that isn’t a self-hosted install, so you can poll it from a script if you want the same view outside the wizard.
When Continue is blocked
Three things hold you on the checks screen:
- The instance isn’t reachable yet, which is normal on a first boot while containers are still starting
- The results are still revealing, so you haven’t seen them all
- You’re in Production and at least one check reads Failed
Test flight never blocks on results. If a check fails after you’ve fixed something, Re-run pre-flight re-probes everything without reloading the page. Snapshots are cached for three seconds, so give it a moment rather than clicking repeatedly.
The fix for a Failed row is almost always restarting the container named in its Container column, for example docker compose up -d clickhouse. If it keeps coming back red, Troubleshooting covers the common causes service by service.
Launch mode is not a profile
Every container the checks probe is one of the always-on 13, so a light install and a full one produce identical results. You can’t fail pre-flight by running the smaller stack. Profiles decide which containers run at all and are set in .env before the stack starts. Launch mode is a one-off choice in the browser that changes nothing about your deployment.
Dive deeper
Questions & Discussion