Publish a flow to the marketplace
Compile a flow.yaml with axiom flow compile, then promote the artifact to the public marketplace with axiom flow publish so other tenants can fork it or import it as a subflow.
View as Markdownaxiom flow publish promotes a compiled flow to the public marketplace from
the command line — the same action the editor's Publish button performs.
Once published, every Axiom tenant can discover the flow, fork it, and import
it as a subflow inside their own flows.
You publish a compiled artifact, not a flow.yaml source file. So the two
steps are always compile, then publish:
# Compile the flow.yaml in the current directory; prints the artifact id.
axiom flow compile
# → compiled flow artifact 01J8Z6K3W9XQ4M7C2YB5N0A1RT
# Publish that artifact to the public marketplace.
axiom flow publish 01J8Z6K3W9XQ4M7C2YB5N0A1RTPrerequisites
- A login session. Both
axiom flow compileandaxiom flow publishrequireaxiom login; publishing without it printsNot logged in. Run "axiom login" first.and exits. - A compiled artifact. Run
axiom flow compilefirst and copy the artifact id it prints. Publishing takes that id as its only positional argument.
Publish a compiled artifact
axiom flow publish 01J8Z6K3W9XQ4M7C2YB5N0A1RTBecause publishing is irreversible, the command prints a confirmation prompt and
waits for y before doing anything:
Publishing flow 01J8Z6K3W9XQ4M7C2YB5N0A1RT makes it publicly visible to every Axiom tenant.
This cannot be undone — published flows are immutable.
Publish? [y/N]On confirmation it makes the flow publicly visible and prints:
✓ published flow 01J8Z6K3W9XQ4M7C2YB5N0A1RT
visibility: public — marketplace-visible, forkable, importable as a subflow
published as me/greeter@1.0.0A published artifact can never be edited or unpublished. To change a published
flow, edit its flow.yaml, run axiom flow compile again to get a new
artifact id, and publish that.
Mocked artifacts are rejected
A flow carrying authoring fixtures — a flow.yaml with a mocks: section —
cannot be published: a published flow must run its real nodes, so the
marketplace never contains a flow that answers from canned data. axiom flow save carries the section into the saved document, and publish then refuses it
with cannot publish a flow whose saved source declares <n> authoring mock(s);
a compiled artifact whose graph embeds fixtures is refused the same way.
Nothing is stripped silently — going live means removing the fixtures, saving that, and publishing the mock-free document:
axiom flow mock rm --all support-triage.flow.yaml # or delete the mocks: section by hand
axiom flow save support-triage.flow.yaml # → graph id, now mock-free
axiom flow publish <graph-id>See Mock nodes while authoring a flow for what
fixtures are for and what axiom flow compile --no-mocks is for instead.
Publish without the prompt (CI and scripts)
Pass --yes (-y) to skip the confirmation — required when stdin is not a
terminal, or the command blocks waiting for input:
axiom flow publish 01J8Z6K3W9XQ4M7C2YB5N0A1RT --yesAdd --json to emit a single machine-readable object instead of the human
lines, so a script (or an agent) can confirm the result programmatically:
axiom flow publish 01J8Z6K3W9XQ4M7C2YB5N0A1RT --yes --json{
"artifact_id": "01J8Z6K3W9XQ4M7C2YB5N0A1RT",
"visibility": "public"
}A flow is fully qualified and versioned
Since ADR-173 a flow carries the same identity a package does, declared in its
flow.yaml:
name: your-handle/greeter # REQUIRED, fully qualified — one slash
version: 1.0.0 # REQUIRED semverPublishing refuses an unscoped name (greeter) or a missing/non-semver
version, so a flow can never enter the marketplace without an identity that
distinguishes it from another author's flow of the same short name.
Versions behave like a package's:
- Bump
versionand publish again → the flow's existing marketplace card gains a new entry in its version dropdown. It does not become a second card. - Publish the same version again → that version re-points at your newly compiled graph. The previous graph id keeps working, so anything already pinned to it (a deployed graph, a subflow reference) is unaffected.
List and resolve versions by name:
# every published version, newest first, each with its graph id
curl -s https://api.axiomide.com/api/flows/your-handle/greeter/versions
# resolve one version (omit @version for the latest) to its graph id
curl -s https://api.axiomide.com/api/flows/your-handle/greeter@1.1.0axiom flow run still takes the graph id — the fully-qualified name is how you
find the right one.
How people find your flow
Both marketplace surfaces — the website and the editor's Marketplace panel — search
published flows over the same fields: the flow's name, its description, and
the AI summary, tags and use-cases the enrichment pass derives from it. A search is
not a name match, so a flow called me/coordinate-to-nws-forecast is found by
"weather" when its description says so.
That makes the description: in your flow.yaml the main thing standing between
your flow and the person looking for it. Write it as the sentence someone would type
when they don't yet know your flow exists — what it does, to what input, from what
source — rather than a restatement of the name.
The flow CLI lifecycle
axiom flow publish is the last verb in the command-line flow lifecycle. The
full set of axiom flow verbs takes a flow from an empty file to a public
artifact without ever opening the canvas:
| Verb | What it does |
|---|---|
axiom flow new <handle>/<name> | Scaffold a starter <name>.flow.yaml with two example nodes and an edge. The name must be fully qualified. |
axiom flow validate [flow.yaml] | Run local structural checks (required fields, unique node ids, edge shape). No login needed. Add --json for structured output. |
axiom flow compile [flow.yaml] | Resolve each node against the registry, auto-lay-out unpinned nodes, and compile the graph into a runnable artifact. Prints the artifact id. Requires login. Add --json. |
axiom flow run <artifact-id> | Invoke a compiled artifact and print its result. Pass input with --data/-d (default {}), wait time with --timeout (default 60 s), and --json for the full response. Requires login. |
axiom flow pull <artifact-id> | Materialize an existing compiled artifact back into an editable flow.yaml (--out/-o, default flow.yaml). |
axiom flow mock add/rm | Add or remove a node's authoring fixture in the flow.yaml mocks: section. See Mock nodes while authoring a flow. |
axiom flow publish <artifact-id> | Promote a compiled artifact to the public marketplace. Requires login. |
A typical command-line session runs them in order:
axiom flow new me/greeter # write greeter.flow.yaml (name: me/greeter, version: 1.0.0)
axiom flow validate greeter.flow.yaml # local sanity check
axiom flow compile greeter.flow.yaml # → artifact id
axiom flow run 01J8Z6… -d '{"name":"Ada"}' # try it
axiom flow publish 01J8Z6… # share itCLI and editor publish are the same action
axiom flow publish and the editor's Publish dialog are the same
action — both promote the artifact to the same public marketplace listing
with the same final visibility. Publishing from the CLI and publishing from
the canvas produce an identical marketplace listing; use whichever surface you
are already in.
With this verb, all three Axiom artifact types now have full command-line ↔ UI parity for both creating and publishing:
- Nodes/packages —
axiom pushthenaxiom publish <package>@<version>, or the console. - Flows —
axiom flow compilethenaxiom flow publish <artifact-id>, or the editor's Publish button.
Next steps
- Run your first flow — build a
flow.yamland run it before you publish. - Nodes, packages, and flows — how a published flow becomes an importable subflow.
- Author and consume packages and flows with Claude Code — drive this whole lifecycle from an AI agent.
- Browser caching for flows and nodes — if this flow only reads immutable or reference data, declare it cacheable before you publish so browsers can reuse the response instead of re-invoking it.