Skip to main content

Baselines

A baseline is a complete, production-shaped product repository that Orunbase can rebuild for you under your own name: your GitHub organization, your cloud account, your product name and domain. Building one takes about an hour and ends with a repository that has its own CI, its own infrastructure, and a product live on stage and prod.

Baselines are listed in the baseline registry, which the console draws as the Pick screen ("What are you building?") and the orun CLI prints with orun baseline list. Each row is a baseline you may build into a workspace; a workspace that has already been built from one shows what it was built from, and at which tag, above the list.

Two senses of "baseline"

This page is about the registry: products the platform builds for you. What is Orunbase? and Deploy your own use the same word for orun-cloud itself — the open, forkable repository the platform runs from. That is a fork you make by hand; a registry baseline is a build the platform runs.

The catalogue​

Orunbase maintains these public baselines today. Each one is pinned to a tag in its source repository, and the tag is what every build reads.

BaselineBuildsRequiresTierTagBuild time
cirrusA worker fleet behind one edge API, a Next.js console, a D1 + KV data plane, migrations, and CI that converges on merge. Cloudflare only.CloudflareFreebaseline-v12~60 min
lumenThe Cloudflare + Supabase multi-tenant SaaS: worker fleet, edge API, console, Terraform data plane, migrations, and CI.Cloudflare, SupabaseFreebaseline-v29~75 min
multi-tenant-saasLumen's architecture on its own release line, under the Sourceplane brand defaults a new product inherits.Cloudflare, SupabasePaidbaseline-v3~75 min

Two more rows — stratus (six ASP.NET Core services on Azure) and stratus-coolify (the same services on a Coolify server you run) — are unlisted: reachable by id, listed to nobody, paid. Build times are measured, not guessed.

An account on the Business plan may register its own baselines beside these, private or unlisted; see Publishing a baseline.

Three documents​

A baseline is described by three documents, each owning one thing and none restating another:

  • The registry row — identity and commerce: the id the console routes on, the display name and summary, visibility (public, unlisted, private), tier (free or paid), the source repository, the pinned tag, the measured expectedMinutes, the providers it requires, and manifestPath, the path of the blueprint card inside the source repository. Orunbase-maintained rows live in infra/baselines-registry/baselines.yaml in orun-cloud; account-registered rows are written through the API.
  • The blueprint card (blueprint.yaml) — the build contract, fetched from the source repository at the pinned tag. It declares the inputs the console asks for (each with a validation pattern, or a rule to derive it from another value or from the repository), the provider integrations the build requires, a preview of the secrets it will mint (names, never values), the programme (one epic and a milestone per phase), the build document it runs, and the URLs a finished build must answer. Everything the console shows about a baseline comes from this file.
  • The build document (repo-blueprint.yaml) — the phases and hooks orun places and runs, named by the card's bootstrap.blueprint. The console never reads it directly; the engine does.

The card carries no tag of its own: it is fetched at the tag the registry pins, so a tag inside it could only ever be a second, rotting copy.

Blueprint-driven and shell-layer baselines​

Every public baseline today is blueprint-driven: its row declares a manifestPath and nothing else, every phase is declared in its build document, and a runner executes it. A shell-layer baseline (stratus and stratus-coolify) declares two more paths on its row — briefPath, an agent's task brief, and umbrellaPath, the workflow the brief runs — and is built by an agent reading the brief. A row declares both or neither; one without the other is a row someone edited halfway, and the registry refuses it.

Both shapes build through the same door, in the same sandbox, under the same gates. They differ only in what the build session is handed: a brief, or a build to run.

Who may build what​

Three things decide whether you can press Build on a given baseline in a given workspace:

GateRule
RoleYou must hold the admin role in the workspace. Starting a build lends admin to the build session, and nobody may mint what they do not hold. An agent session can never start a build.
PlanA paid baseline needs a paid plan on the account. Free baselines — Cirrus and Lumen — build on any plan. An account's own registered baselines are never plan-gated at build time.
ReadinessEvery provider in the card's requires.integrations must be connected in the workspace. GitHub is not a connection row — it arrives as the GitHub App installation plus the repository link — so a card requiring github and cloudflare asks you to connect Cloudflare and to link a repository.

The console disables the button when a gate is unmet and says why; the server enforces the same gates on the request, because a disabled button is a suggestion.

Credits​

A build debits a flat admission fee from the account's credits at the moment it starts — after every gate has passed and before anything has run. The fee is the price of the whole build: the session's own usage is zero-rated under it. A balance that cannot cover the fee refuses the build with 412 credits_exhausted, and a build that fails to start after the fee was taken is refunded.

What a build does​

The build runs in a sandbox Orunbase provisions — 4 vCPU, 8 GiB memory, 10 GiB disk, with open egress because Terraform dials arbitrary provider endpoints — with a time-boxed admin grant on your workspace and credentials minted from your provider connections for this build only. The sandbox lives for two and a half times the baseline's expected build time, floored at two hours, so a slow provider cannot end a build mid-Terraform.

Inside it, the engine runs orun agent serve --driver bootstrap, which runs orun baseline new <id>@<tag> --local --run-hooks --resume: it fetches the source repository at the pinned tag, reads the card, and places the build document's phases one by one, running each phase's hooks — creating branches, opening and landing pull requests, minting secrets, provisioning infrastructure, deploying — into the repository you chose. The tag is pinned by the platform when the build starts, so a registry that publishes a new tag mid-build changes nothing about the build already running.

Each phase opens a milestone under one epic in the workspace's Work ledger, so the shape of the work is visible before the build starts and every pull request it lands is addressable afterwards. When the last phase lands, the card's verify URLs are probed for each environment, and the workspace records what it was built from — the baseline id and the tag — so it can later be told that a newer tag is available.

Where to watch it​

  • The console's Overview. Starting a build lands you on the workspace Overview with the build panel open beside it: a phase list with a live line for the running phase, the epic and each phase's task and pull request as chips, a full log, and the verify links once it finishes. The panel's state is the engine's and survives navigation and reload; a Build pill in the masthead names the current phase (02-foundation 1/8) from every page. See Build from the console.
  • The session. The build is an agent session (as_…), so its transcript is on the session's own page under Agents, reachable from the panel's footer. See Agents.

A build started from the CLI is watched in the same two places; the CLI prints the session id and returns.

One build per repository​

A repository holds one build at a time. The platform takes a lease on the repository before anything is created and refuses a second build with 409 conflict, naming the build that holds it and who started it. The lease is released when the build reaches a terminal state and on every failure path, so a build that never started never blocks the next one.

Publishing a baseline​

A baseline is pinned to a tag, never a branch: a moving ref would silently change what every workspace builds. Publishing a new version is moving the tag, and the order is fixed — push the tag in the baseline's own repository first, then move the registry. What a build reads first is fetched from the source repository at that tag, so a tag that does not exist yet means every build 404s.

Before a tag moves, the platform proves it: that the ref is a tag and not a branch or a commit, that the files a build reads first are in it (the brief and umbrella for a shell-layer row, the card for a blueprint-driven one), and that the card parses. A tag that fails any check leaves the registry untouched, with the reason.

Who moves the tag depends on who owns the row:

  • Orunbase-maintained baselines move by pull request on infra/baselines-registry/baselines.yaml. The baselines-registry component reconciles the file into the registry on every merge and preflights every declared path at every declared tag, refusing the whole sync if one is missing. A publish call against one of these rows is refused with a message that says so.
  • Account-registered baselines are registered with orun baseline register and moved with orun baseline publish <id> <tag>, which runs the same proof. Registering is a Business plan feature; the source repository must be one the account has connected through the GitHub integration, and public visibility is granted by Orunbase, not set by the account. The flags are in the orun baseline reference.

A retired row stays in the registry, so a workspace built from it can still name what it is.