Public beta — not for production use. Data may be wiped at any time. Questions? Contact us.
Documentation menu

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 Markdown

axiom 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 01J8Z6K3W9XQ4M7C2YB5N0A1RT

Prerequisites

  • A login session. Both axiom flow compile and axiom flow publish require axiom login; publishing without it prints Not logged in. Run "axiom login" first. and exits.
  • A compiled artifact. Run axiom flow compile first and copy the artifact id it prints. Publishing takes that id as its only positional argument.

Publish a compiled artifact

axiom flow publish 01J8Z6K3W9XQ4M7C2YB5N0A1RT

Because 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.0

A 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 --yes

Add --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 semver

Publishing 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 version and 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.0

axiom 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:

VerbWhat 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/rmAdd 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 it

CLI 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/packagesaxiom push then axiom publish <package>@<version>, or the console.
  • Flowsaxiom flow compile then axiom flow publish <artifact-id>, or the editor's Publish button.

Next steps