Release preparation
Ask the agent to get a release to production ready, read the report it produces, and learn the seven gates that decide whether it may promote alone.
A release report tells you whether staging is ready to go to production, and whether the agent may take it there itself. You ask for one, Loomplane works it out, and you read the answer. Nothing ships unless someone asks.
Ask for a release
Pick whichever is closest to hand.
On the project's page, choose Prepare release. Choose the staging and production environments, untick any source you want to hold back, and submit. You land on the report.
From a terminal:
loomctl release prepare checkout-api --wait
loomctl release report rrep_abc123Or ask the agent in a chat, as in "release checkout-api to production". It starts the same preparation on your behalf.
You need deployment:create on the project and agent:use. The agent has to be on for the workspace. The project needs a staging environment and a production one.
Only one preparation can run per production environment at a time. If a plan is already waiting for a decision there, the request fails and names it. You can replace that plan by ticking Replace that plan in the dashboard or passing --replace to loomctl release prepare. The agent never replaces someone's open plan for you. A plan the agent left waiting after a review stopped is different: the next preparation for that environment replaces it, unless it can reuse it.
What the report holds
Loomplane plans a promotion from staging to production, collects the evidence, and the agent reviews it. The report shows:
- The state: planning, reviewing, waiting for a person, promoted by the agent, approved, and so on, with the reason.
- The seven gates, each passing or failing, with a sentence saying why.
- For every source, whether staging is ahead of production, the commits between them, and any database migrations, with their patches.
- Which images the plan reuses and which it builds again.
- How long staging has run these commits, and whether it was healthy.
- The production canaries of each changed service, and what a post-deploy watch would cover. A service no canary ran for says so.
- Agent reports still open on staging, the agent's budget, and any evidence Loomplane couldn't read.
- A section called "From the agent", with the concerns it noted.
Commit titles, authors, patches and the agent's concerns come from outside Loomplane. The dashboard shows them as plain text, and the concerns as quotes. loomctl release report prints them in quotation marks on one line, so you can tell them from Loomplane's own words.
The seven gates
Loomplane computes every gate from its own records. The agent can add a reason to ask a person. It can never clear a gate or edit the evidence. A gate that needs evidence Loomplane can't read fails, so missing evidence always means a person decides.
| Gate | It fails when |
|---|---|
| 1. autonomous promotion | The project's autonomous promotion switch is off. The person who asked can't approve production releases in the project. The release was asked for in chat. The release reuses a plan someone else made. |
| 2. promotes what staging runs | The plan isn't the one this preparation built, it changed since it was read, it isn't a promotion from staging to production, or staging no longer runs the commits the plan pins. |
| 3. clean plan | The plan isn't ready, has problems or warnings, deletes or replaces anything in production that holds data, sets a default backup schedule, moves production back to older code, promotes an older manifest than the latest, brings a source production has never run, or has a diff Loomplane couldn't read in full. |
| 4. staging soak | Staging hasn't run the plan's commits long enough, isn't healthy, can't be judged, or its own last release failed or went unverified. The minimum is the project's setting, or one hour if you haven't set one. |
| 5. safety net | A changed service has nothing guarding it once live, a data-bearing resource is updated, production's last release is unverified, or a service's last canary failed and no later one promoted. |
| 6. nothing open on staging | An agent report is still open on staging. |
| 7. budget | The agent's budget is spent, or what's left is under the reserve for the post-deploy watch: $1, or 10% of the limit if that's more. |
What always goes to a person
Some releases never pass, whatever the gates say about the rest.
- Anything that destroys production data. This one doesn't depend on a gate: it always goes to a person.
- Services on Kubernetes, a server, Vercel, DigitalOcean, Firecracker or Cloudflare Workers. Loomplane has no canary or watch it can judge there.
- Updates to anything that holds data, and a production environment moving back to older code.
- Releases from GitLab or Bitbucket. Loomplane can only compare commits on GitHub for now, so it can't read those diffs.
- A source's first production release, on any host. Production has never run it, so there's nothing to compare its changes to. Gate 3 names it: "worker has never run in production, so its changes can't be compared".
- A first production release. Nothing in production has been watched yet, so the evidence isn't there.
- A failed canary, until a later canary of that service promotes.
- A plan that promotes an older manifest than the latest.
Who asked also matters. A release prepared from chat never promotes on its own, because the agent chose to start it and not you. A release that reuses someone else's open plan needs a person too. And if the person who asked can't approve deployments, the review still runs and the plan waits for someone who can.
When autonomous promotion is off for the project, the agent still asks before production. It starts off for every project.
When a person decides
A release that fails a gate, or that always asks, ends up in Needs a person on its report, with the failed gates listed. The approval request goes to the project's team, or the workspace admins if the project has no responsible team. If you asked for the release and you're not on that team, the request doesn't reach you, so keep the report open to follow it. Approve it as you would any plan, in the dashboard or with the line the report prints:
loomctl approve plan_abc123 --revision rev_7Approving a production release starts its canary, as one decision. If the plan changed after it was reviewed, say because staging deployed again, the approval is refused as stale and the report says so. Prepare the release again.
When every gate holds
When you asked from the dashboard or loomctl, you can approve production releases in the project, and every gate passes, the agent approves the plan with the revision it read. The report shows the decision as made by the Loomplane agent, and the canary takes over from there. It's the same approval a person would make, in the audit log under the agent's name.
Who hears about it
When a release is promoted, goes stale, stops, is blocked or fails, Loomplane sends a notice to the person who asked and the project's team. If the project has no team, it goes to the workspace admins. Open it to land on the report.
You can stop a preparation that's still going with Cancel or loomctl release cancel. The person who asked can do it while they hold agent:use, and so can anyone who can approve deployments. The plan, if there is one, waits for a person.
Once every gate has held and the agent is promoting, you can't cancel. Its approval may already be landing, and a cancel then would leave a report saying cancelled while production ramps. Read the report again in a moment: it settles as promoted, or as stopped with the plan waiting for a person if the approval didn't go through.