Roadmap

This page reflects current intent for Flux releases. There are no firm dates. The list is reviewed quarterly and updated when priorities shift. Treat it as a snapshot — not a commitment — and read Release notes for what has actually shipped.

The candidates below come from two sources: the limitations documented across this site during Phase 4–7 verification work, and the longer-arc direction discussions that shape what Flux becomes after 1.0. Where a candidate has a tracking issue or pull request, it is linked; where it does not, the gap is called out honestly.

Shipped in 0.36–0.53

Two of the design-point limitations previously listed as candidate work have shipped in the 0.36–0.53 line:

• Scheduler leader election — done, via the cheapest path this page predicted: PostgreSQL advisory locks. Multiple server replicas now run safely; scheduler dispatch and retention are fleet-wide singletons per cycle, with no leader election to configure. See High availability.
• Alembic / migration tooling — done. The schema is Alembic-managed: migrations run automatically on database open, legacy create_all databases are stamped and upgraded in place, and flux db upgrade|current|history gives explicit control. See Upgrades and migrations.

The same line also shipped work that was never on this page — pluggable runners, transient durability, event-driven dispatch, worker capacity and drain, execution-history retention, and the hardened Docker image. The 0.54–0.56 line continued in that vein, again with items that never appeared here as candidates: dynamic routing (scoring policies over worker-advertised metrics), worker self-health (event-loop-lag detection with automatic dispatch exclusion), sticky routing for relayed calls, and standing approvals. See Release notes for both rollups.

Shipped in 0.35.0

The 0.35.0 release closed the most visible correctness gaps in 0.33.x — compounding retry backoff, retry-attempt timeouts, Graph conditional edges and cycle detection, schedule history, the /health 503 behavior, config precedence, the MCP transport default, worker SIGTERM handling, OTLP protocol configurability, failed-task span status, trace propagation to resumed and cancelled executions, and a set of LLM provider fixes including API-enforced Anthropic structured output. See Release notes for the full list.

Next minor — candidate work

Gaps still open after 0.56.0. Each candidate has a specific user-facing symptom and a known implementation path.

• Replay testing tooling. A first-class testing harness for “given this event log, does the workflow replay deterministically?” Today this is hand-rolled per project. A flux test replay CLI that takes a recorded execution and re-runs it against the current workflow code would catch the most common class of replay drift bug.
• First-class S3 (and S3-compatible) output storage. Today’s output catalog is local-filesystem or Postgres-blob. An S3 backend with content-addressed keys is the most-requested integration after the LLM providers and would unblock larger-than-RAM workflow outputs.
• Automatic saga rollback. A @workflow.saga (or equivalent) decorator that triggers rollback= for previously-completed tasks when a downstream task fails. Probably opt-in rather than default — the current “manual orchestration” semantics are the right behavior for many users and changing them silently would be a breaking change.

No GitHub issue links are reproduced here yet; the canonical list of milestones lives at github.com/edurdias/flux/milestones.

Mid-term

Larger work items that sit a release or two out. Specifics firm up as the current line stabilizes.

• Official Helm chart. Deployment recipes today are Compose, raw Kubernetes manifests, and Terraform/Pulumi shapes for cloud-managed Postgres. An official Helm chart with values for the server replicas, the worker pool, and the MCP server is the right packaging for production Kubernetes users.
• Managed cloud offering. Whether this lands inside this timeline depends on commercial priorities outside the scope of this page. The shape under discussion: a hosted Flux server with regional deployments, BYO worker pool, and SSO. The OSS surface and the cloud surface stay one codebase.
• Plugin API for LLM providers. Today the four provider implementations live in flux/tasks/ai/. A documented plugin API would let third parties ship Bedrock, Cohere, Mistral, or local-inference providers without forking. The shape: a Provider protocol with the same complete / stream / tools / response_format surface, registered via entry points.
• Full OpenTelemetry propagation across call_workflow. Wire the trace context through the workflow-to-workflow dispatch path so a parent workflow’s trace continues into its child. Today the child opens a fresh trace and the relationship is recoverable only through the event log.
• Workflow versioning surface in the UI / CLI. Workflows are versioned today, but the user-facing affordances for “register this version, route schedules to that version, roll the catalog back to last week” are thinner than they should be.

1.0

The 1.0 commitment is operational, not feature-driven.

• API stability. A documented, semantic-versioning policy across the Python SDK, REST API, MCP toolset, and CLI. Breaking changes confined to major versions; deprecations announced one minor in advance.
• Production stability commitment. A documented SLO surface — startup time, scheduler dispatch latency under load, replay throughput per worker — backed by a public benchmark suite (see Performance and benchmarking for the gap that needs filling).
• Multi-language SDK. The chassis is ready for it (the code-tabs component takes a language parameter from day one), and the server is language-agnostic by construction. A first-class TypeScript SDK is the most likely candidate for 1.0; Go is a step further out. The decision point is whether the SDK is a thin REST/MCP client or a full replication of the Python SDK’s ergonomics.
• Audited security posture. Token issuance, RBAC, secrets handling, and OIDC integration paths under third-party review. The current implementations are honest and tested but unaudited.

What is intentionally not on the roadmap

Things that come up periodically and are deliberately not planned:

• A built-in message broker. Flux uses Postgres for dispatch. Adding Redis, Kafka, or NATS as a broker is not on the roadmap — the durability story is built around the event log and an additional broker would complicate it without solving a real problem we have.
• A UI replacement for the CLI. The CLI and REST API together cover the operator surface. A separate web UI may exist as a separate project, but the documented operator path is CLI plus REST plus MCP.
• A workflow visual editor. Workflows are Python code. Diagrams of running workflows belong in observability tools (Grafana, Datadog, custom dashboards), not in Flux itself.

How this page changes

Reviewed at the end of each release cycle and at the start of each quarter. Items that ship move to Release notes. Items that are dropped explicitly are noted in a “not on the roadmap” line. Items that slip to a later release are renamed, not deleted, so the trajectory stays visible.

The roadmap is a snapshot of current intent — not a contract. If a deployment decision depends on a specific item shipping, watch the GitHub milestones for the firm signal and treat this page as the rough direction.