Installation

Quick install (CLI today)#

The canonical install command on macOS + Linux:

curl -fsSL https://staging.oz.com/install/arcflow | sh

This is the only install URL the docs publish. If a stale CLI build surfaces a different URL (any other domain, including a deployment-host alias), prefer the canonical command above; the published install URL is the source of truth.

What this gives you today: the arcflow CLI binary at ~/.arcflow/bin/arcflow (or platform equivalent), and that's it — a single executable. The install message will say "Binaries: arcflow" (singular) — that is the current shipping scope.

What this does NOT give you today: the Python wheel, the npm package, or the Rust crate. Those are planned for RAM-C2 / 2026-Q3 on their respective public registries (the current shipping status for each binding lives in the install matrix below). Until they publish, the public-registry installs for oz-arcflow / arcflow will fail with No matching distribution. See Using ArcFlow from Python or Node today below for the recovery path.

ArcFlow ships across multiple registries. This page is generated from a single source of truth — the engine's RELEASE-MATRIX.toml. Every binding listed below was probed by CI before this page was published; planned artifacts are flagged with their target quarter and never advertised as if they were live.

Upgrading from a pre-2026-05-14 install (the v1.x line)#

If you have an arcflow binary installed from before 2026-05-14 — anything reporting v1.x.y when you run arcflow --version — your arcflow upgrade command cannot migrate you to the current line. The v1.x line was retired 2026-05-14 when ArcFlow re-versioned to alpha (current line: v0.7.x and v0.8.x); legacy v1.x binaries hold their own retired upgrade-channel URLs in their compiled bytes and cannot self-correct.

Recovery: reinstall via the canonical install script.

curl -fsSL https://staging.oz.com/install/arcflow | sh

(See Quick install at the top of this page for the URL-stability context — the install URL standardized on staging.oz.com is what works today; the production-canonical oz.com/install/arcflow resolves once the oz-platform dev → production deploy lands, but the docs publish the working URL.)

After reinstall, verify:

arcflow --version    # should show v0.7.x or v0.8.x (current line)
arcflow upgrade      # works correctly from v0.7.x+; pulls the latest cut

If you're already on v0.7.x or v0.8.x: nothing to do. arcflow upgrade works correctly on the current line; you can keep using it.

Why this happens (one paragraph)#

ArcFlow moved from 1.x to 0.x versioning per an explicit operator directive — the alpha line restarts at 0.x, with v1.0 reserved for the first production-ready release. The arcflow upgrade code in any binary shipped before that pivot was compiled against the retired v1.x release channel; it has no awareness of the line move. The fix is to download a current binary via the install script (above), which then has the corrected upgrade-channel awareness for every future arcflow upgrade call. This is a one-time recovery per machine; no further intervention needed.

Using ArcFlow from Python or Node today#

If your project's pyproject.toml or package.json depends on oz-arcflow / @ozinc/arcflow and pip install / npm install returns "No matching distribution found", the cause is the publish gap shown in the matrix above — the SDK wheels are not yet on the public registries.

Until they ship, the CLI is the complete answer for most workflows. Install it with the curl one-liner at the top of this page and address ArcFlow through the JSON-over-stdin transport:

arcflow query "MATCH (n) RETURN count(*)" --json

The JSON-over-stdin transport is identical in shape to what the SDK wraps; everything you would call through the SDK is reachable from the CLI today. When the SDK wheels publish, switching from CLI shell-out to in-process calls is mechanical — the result envelopes are byte-identical.

How this page stays accurate#

The matrix above is rendered from release-matrix.json, published on every release. CI asserts on every commit that:

• A status: shipped artifact's registry returns HTTP 200.
• A status: planned artifact's registry returns HTTP 4xx (no false advertising).

If the manifest is unreachable at build time, the docs build fails — there is no fallback to a hand-rolled list. The matrix above is the live data; this page never ships an install command that the registry can't actually serve.

Verify installation#

import { openInMemory } from '@ozinc/arcflow'
 
const db = openInMemory()
db.mutate("CREATE (n:Hello {message: 'It works!'})")
const result = db.query("MATCH (n:Hello) RETURN n.message")
console.log(result.rows[0].get('message'))  // "It works!"
db.close()

from arcflow import ArcFlow
 
with ArcFlow() as db:
    db.execute("CREATE (n:Hello {message: 'It works!'})")
    for row in db.execute("MATCH (n:Hello) RETURN n.message"):
        print(row)  # {'message': 'It works!'}

The TypeScript example assumes the arcflow npm package is installed; the Python example assumes the arcflow Python wheel is installed. The matrix above shows you the install command for whichever path is currently shipped.

Environment variables#

Requirements#

• Node.js 18+ (LTS recommended) for the npm path.
• Python 3.8+ for the pip path.
• No native build tools required — pre-built binaries are bundled in the installable artifacts.

Pre-release / nightly builds#

Per-commit pre-release artifacts are not published. The canonical release path is the GitHub Release on ozinc/arcflow — pin to a published tag for reproducibility.

For customer projects: pin oz-arcflow==X.Y.Z (Python) or @ozinc/arcflow@^X.Y.Z (npm) against the public registry. Don't vendor wheels — they go stale on every release, and the next teammate who clones the repo gets a binary that doesn't match the docs they're reading.

The vendored wheel rebuilds whenever the engine code changes; commit it alongside the test that depends on it for reproducible audit across sessions.

See Also#

• Quickstart — first query in under 5 minutes
• Project Setup — world model workspace layout and configuration
• Language Bindings — Node.js, Python, Rust, Go, WASM, and CLI
• Cookbook — runnable, manifest-aligned recipes