Build from the console
The console builds a baseline through a five-step setup flow — Overview → Repository → Providers → Product → Review — one decision per screen, each step verified against live state rather than a checklist you tick. When every gate is met, Start the build lands you on the workspace Overview with the build panel open beside it, and that panel is where the hour is watched.
This page follows the flow with cirrus (Cloudflare only) as the worked example.
Before you start
- Your role is admin in the workspace. Starting a build lends admin to the build session, so the platform requires it of you.
- The GitHub App is installed on the organization that will own the product repository. See GitHub integration. The Repository step shows
GitHub installed on <org>once it is. - The provider is connected, or will be — the Providers step connects it in a dialog over the flow, or you can connect it first under Integrations (Connecting providers). Cirrus needs Cloudflare; Lumen needs Cloudflare and Supabase.
- Credits cover the flat admission fee, and for a paid baseline the account is on a paid plan. See Credits.
Find the registry
There is no Baselines row on the workspace rail: picking a baseline is choosing what to build, so it is offered on the way to a workspace rather than inside one. Open the workspace selector in the masthead and choose Start with a baseline, which opens the account's baseline registry. From a workspace you already stand in, /{account}/{workspace}/baselines renders the same list with every row opening that workspace's setup flow. The onboarding a new account walks through offers the same registry as a starting point.
The registry is the Pick screen: one row per baseline, with its name, a one-line summary, provider tiles, and a tag — ~60 min, Paid, Building while a build is running, Live once one has finished. Your account's own registered baselines are listed above Orunbase's. A paid row the plan does not cover is drawn dimmed and does nothing; open it from the account's registry (/settings/account/baselines/{id}) to see its facts and a Compare plans link. A workspace that was built from a baseline shows what it was built from — and that a newer tag is available, when the registry has moved — above the list.
Choosing a row opens /{account}/{workspace}/baselines/{id}, the setup flow.
Step 1 — Overview
What you are building, from the card's own words: the lede, the architecture by layer (for cirrus: api-edge and web-console-next at the edge, twelve bounded-context Workers, D1 and KV, GitHub Actions and db-migrate for delivery), and the outcome — live on stage and prod, migrations applied on merge, its own CI from the first phase. The source and tag are shown as cirrus@baseline-v12.
The stepper across the top counts the gates: two or three, depending on whether the baseline asks you for anything. You may read ahead to any step; only Review is unreachable over an unmet gate.
Step 2 — Repository
Where the product lives. The step lists the workspace's linked repositories, and offers Link a repository (a picker over what the installation can see) and Create one (a new private repository on the installation, named here). Selecting a repository wires it: the workspace link that allow-lists it for OIDC push is created, and then the repository link (repl_…) with agent write access. The card reads OIDC push · agent write when both are in place.
A build needs the repository link, the repl_… record that binds a project to one repository on the GitHub connection. It is not the same record as the allow-list link orun cloud link creates for remote state. The Repository step creates both; the repository's Git tab under Settings → Git repos is the other place to create a repository link. The orun CLI cannot. See State plane.
Choosing a repository also fills every input the card derives from it — for cirrus, reponame from the repository's name and githuborg from its owner.
Step 3 — Providers
What the product deploys to: one card per provider the baseline requires, with Connect on the right. Connecting opens the provider's OAuth consent in a popup over the flow (or a token paste, for providers that offer it), and the card turns green with a Connected pill when it lands. Under each provider are the secret names its connection will mint for the build — for cirrus, CLOUDFLARE_API_TOKEN, CLOUDFLARE_D1_TOKEN and CLOUDFLARE_ACCOUNT_ID. These are a preview: tokens are minted per build from the workspace's connection, never typed, shown, or stored in the console. Keys that already exist in the workspace are kept.
The stepper names the provider when there is exactly one ("Cloudflare"); GitHub appears here only as the installed on <org> line, because it was satisfied by the Repository step.
Step 4 — Product
The inputs the card asks for, in the card's order, each validated against the pattern the card declares before Continue is enabled. Cirrus asks for three:
| Input | Meaning | Example |
|---|---|---|
productname | The display name people see in the console header, emails, and docs | Acme Cloud |
productdomain | The apex domain the product answers on; it does not need to exist yet | acme.dev |
subdomain | The workers.dev subdomain of the Cloudflare account this builds into | acme |
reponame and githuborg came from the repository; apibaseurl is derived as https://api.{productdomain}. A baseline whose card asks for nothing has no Product step and two gates instead of three.
What you type is saved as a draft on the workspace as you go, so the flow resumes where you left it — and the Overview's card counts the steps still to go.
Step 5 — Review
Everything the build will use, with the facts the previous steps produced: the repository, the provider, the product values, and a line such as 3 secrets minted · 8 pull requests · 1 epic · cirrus@baseline-v12. The pull-request count is the card's milestone count, one per phase; for cirrus the epic is Infra baselining — {productname} with milestones 01-scaffold through 08-docs, where 07-domain runs only when a domain is asked for.
Start the build is enabled when every gate is met. It reads Upgrade to start on a paid baseline the plan does not cover, and Already building while a build holds the repository. Pressing it calls the platform, which enforces every gate again, takes the repository lease, debits the admission fee, grants the session admin, and provisions the sandbox; the console posts the one-line kickoff and takes you to the Overview.
Watching the build
The build panel opens beside the Overview — a column at desktop widths, full-page on demand — and the Build pill in the masthead names the current phase from any page. The panel shows:
- a header with the build's state and
landed/totalphases, and a meter beneath it; - the epic as a chip into the Work ledger;
- one row per phase, in order: queued, running (with the engine's latest line), landed, blocked, or stopped. Each row expands to its own log and carries chips for its task and its pull request. A phase declared with a condition reads
Only if <input> is setwhile queued; - the full log, in place of the phase list, from the footer;
- the verify links once the build finishes — one per environment;
- a footer with the elapsed clock and a link to the session page under Agents.
/baselines/{id}/progress still resolves for old links and forwards to the Overview with the panel open.
Blocked, stopped, retry
- A blocked phase is one parked on a person: the panel names what it is waiting for, and Done tells the build to carry on.
- A stopped build shows a status strip that names the engine phase it stopped at (
04-workers-restore, not only the milestone it files under) and a Retry from<phase>button. Retry starts the build again from the setup on record — the same repository link and the values the draft kept — and tells the runner to place that phase and every one after it again, so a phase that landed and then failed to converge is done again rather than skipped as "already in place". The button's menu, Start from an earlier phase, lists the landed phases before it; picking one redoes the build from there. The strip turns the moment you click — Retrying from<phase>, with the step it is on (stopping the failed run, starting a new runner, handing the build over) — until the new run's first line arrives. If the setup on record is missing (the draft was discarded, or the repository is no longer linked) the panel sends you to the flow's Review step with everything still filled that can be; its button there is the same retry. - Ask the agent, on a stopped phase, opens an agent session grounded in that phase's failure, and Edit setup returns to the flow's Review step.
Verifying
The card declares what a finished build must answer, and the panel probes it. For cirrus, for each of stage and prod:
https://{reponame}-api-edge-{env}.{subdomain}.workers.dev/health
https://{reponame}-web-console-next-{env}.{subdomain}.workers.dev
So a product built into acme/storefront on the acme subdomain answers at https://storefront-api-edge-stage.acme.workers.dev/health and https://storefront-api-edge-prod.acme.workers.dev/health. The workspace now records that it was built from cirrus at baseline-v12; the registry page shows it above the list, and tells you when a newer tag is published.