> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish a version

> Freeze the current Draft and point production traffic at it.

Publishing is the act of taking your Draft, freezing it, and moving the production pointer to the new version.

## How to publish

From the Flow canvas, top-right → **Publish**. Nora:

1. Runs pre-publish checks (see below).
2. Prompts for a release note.
3. Optionally suggests a canary rollout for high-risk changes.
4. Confirms.
5. Creates the version and moves the pointer.

New runs use the new version immediately. In-flight runs finish on the version they started with.

## Pre-publish checks

Publishing runs a battery of checks. All must pass:

* **All required inputs wired.** No orphan blocks.
* **All Agents have prompts + models.** No blank fields.
* **All tools have descriptions + parameter descriptions.**
* **All secrets resolve.** No broken references.
* **No cycles.** Wiring is acyclic unless you explicitly used a bounded loop.
* **Draft differs from current published.** No no-op publishes.
* **Simulation gate (if configured).** If Flow settings require a simulation minimum pass rate, that runs first.

Failures show a red banner with the specific problem. Fix, retry.

## Release notes

Optional but strongly recommended. Notes appear in:

* The version list.
* The audit log.
* The CLI (`nora flows versions list`).
* Any linked improvement's record.

Good release notes:

> "Tighten refund escalation. Add rule: when user mentions chargeback, escalate. Bump model to higher-tier for `fraud`/`dispute` keywords. Resolves cluster #142."

Poor release notes:

> "Fixes."

Convention: link the cluster ID or improvement ID the publish addresses. Makes audit fast.

## Publishing from the CLI

```bash theme={null}
nora flows publish --note "release 2026-07-31 refund cleanup"
```

Same checks, same behavior. Common in CI:

```bash theme={null}
nora flows publish \
  --note "$(git log -1 --pretty=%s)" \
  --gate-simulation support-golden \
  --min-pass-rate 0.9
```

Simulate first, publish only if the sim clears.

## Canary publish

To canary a new version:

```bash theme={null}
nora flows publish --canary 5%
```

The version is created but only 5% of traffic sees it. Monitor for 24-72h; then:

```bash theme={null}
nora flows canary promote  # roll to 100%
nora flows canary abort    # rollback the canary
```

Traffic split is scope-key-based — the same user consistently hits one version.

## Publishing dependent resources

Some Flow changes require simultaneous updates elsewhere:

* Published a Flow that references a new retrieval preset? The preset needs to be published too.
* Published a Flow using a new tool with a fresh secret? The secret needs to exist.

The pre-publish check surfaces these dependencies; you'll see prompts to publish or update them.

## Who can publish

Owners and Managers by default. Members can edit Draft; they can't publish. Restrict further under **Flow settings → Access**.

## What happens to Draft

Publishing doesn't touch Draft. Your Draft continues to be editable. It's now different from the published version — the "unpublished changes" indicator lights up.

## Reverting a publish

Publishing is not undoable per se — the version exists. But rollback (see [Rollback](/reliable/versions/rollback)) moves the pointer back within seconds, effectively reverting the publish from production's perspective.