This is a big release - a lot has changed under the hood, but the highlights are a new CLI, the introduction of Coflux Studio, authentication, improved execution isolation, and retry conditions.

New CLI

The CLI has been rewritten in Go. Previously, the CLI was part of the Python package - meaning you needed Python installed just to interact with the server. The new CLI is a standalone binary, making it easier to get running.

The CLI now covers a lot more ground:

• coflux submit - submit a workflow and follow its progress in real-time, with a live-updating step tree in the terminal.
• coflux runs inspect and coflux runs result - inspect runs and retrieve results (including error tracebacks).
• coflux logs - fetch logs, or stream them in real-time with --follow.
• coflux manifests - discover, register, and inspect workflow definitions.
• coflux assets and coflux blobs - download assets and retrieve blobs.
• coflux workspaces, coflux pools, coflux sessions, coflux tokens - manage workspaces, pools, sessions, and tokens.
• coflux queue - view pending executions and understand why they're waiting.
• coflux setup - interactive configuration wizard that auto-detects your Python environment.

Commands support outputting JSON (with --output json) for machine-readable output, making it straightforward to script against.

The Python package (coflux) is now a pure adapter - it handles discovery, serialization, and execution of your Python code, but the CLI handles everything else.

Coflux Studio

The web UI has been extracted into a standalone product: Coflux Studio. Studio provides a hosted interface for managing projects, monitoring workflows, and collaborating across teams. You can use it without creating an account - connection to the Coflux orchestration server happens through your browser. But creating an account allows you to use Studio for authentication, and to share access to projects with your team.

The Coflux engine remains fully open-source. Studio connects to your self-hosted server at runtime, so your data stays in your infrastructure.

Authentication

Coflux now supports authentication. There are two modes:

Service tokens can be created and scoped to specific workspaces, making them suitable for CI/CD and production workers:

coflux tokens create --name "CI" --workspaces "production/*"

Studio authentication uses a device authorization flow - run coflux login, approve in the browser, and you're set. The CLI manages token refresh automatically.

Worker connections and blob/log endpoints are now authenticated too, so data is no longer accessible without credentials.

Recurrent targets

Sensors and checkpoints have been replaced with a simpler concept: recurrent targets. A recurrent task or workflow automatically re-executes after completing successfully, running indefinitely until cancelled.

@cf.workflow(recurrent=True)
def poll_for_updates():
    updates = fetch_updates()
    for update in updates:
        process_update(update)

If retries are configured, they take effect first - only a successful completion triggers the next recurrence. Errors stop the cycle.

Retry conditions

Previously, retries would apply to all errors. You can now specify which errors should trigger a retry using the when parameter:

@cf.task(
    retries=cf.Retries(
        limit=5,
        backoff=(1, 30),
        when=TransientError,
    ),
)
def call_external_api():
    ...

The when parameter accepts an exception type, a tuple of types, or a callback function for more complex logic:

@cf.task(
    retries=cf.Retries(
        # ...
        when=lambda e: getattr(e, "status_code", 0) >= 500,
    ),
)
def call_api():
    ...

Errors that don't match the condition fail immediately, without consuming retry attempts.

Execution isolation

Each execution now runs in a fresh Python process. Previously, a pool of long-lived processes handled executions sequentially, which meant state could leak between them. With the new model, each execution gets its own process and working directory, which are cleaned up afterwards.

To keep things fast, the CLI maintains a pool of pre-spawned ("warm") processes ready to pick up work.

Epochs

Behind the scenes, the server now manages data in rotating 'epochs'. This is mostly transparent, but it means the server can manage data growth without losing access to historical runs. Cache lookups, re-runs, and asset references all work across epoch boundaries.

Other notable changes

• 'Repositories' are now called modules to avoid confusion with version control repositories.
• Workspaces are auto-created when first referenced from the CLI, so you no longer need to create them upfront.
• The server now handles graceful reconnection - workers automatically re-register after a server restart.
• Error tracebacks from child executions are cleaner - Coflux-internal frames are filtered out, so you only see your code.
• Serialization now supports additional Python types including sets, tuples, and dicts with non-string keys.

Feedback welcome! (joe@coflux.com)