vs. Temporal

Temporal is the closest peer to Flux in design space. If you’ve read Why durable execution, you’ve seen us point at Temporal as the best-known implementation of the pattern. This page is the honest version of the comparison: what Temporal genuinely does well, where Flux makes different tradeoffs, and how to choose.

What Temporal does well

Temporal has been in production at scale for years. Uber, Stripe, Coinbase, Snap, Netflix and a long tail of others run substantial workflow estate on it; the engine has been hammered on by real failure modes that you can only encounter by running a lot of executions for a long time. That maturity is worth taking seriously.

A few specific things Temporal does that Flux does not match today:

Multi-language SDKs. Temporal has first-class SDKs for Go, Java, TypeScript, Python, .NET, PHP, and Ruby. The Go and Java SDKs are the oldest and most complete; TypeScript and Python are widely used; .NET, PHP and Ruby fill in the corners. If your platform team writes services in three languages and you want all of them to share a workflow engine, Temporal is the obvious answer.

A real cluster. Temporal Server is decomposed into separate frontend, history, matching, and worker services, each independently scalable, with Cassandra, MySQL, or Postgres as the durable store and (typically) Elasticsearch behind the visibility API for search. This is more parts to run, but each part scales on its own axis — history capacity, matching throughput, visibility query load. At very high execution volume, that decomposition is exactly what you want.

Replay testing. Temporal’s SDKs ship a replay-history workflow replayer: you fetch a recorded history, point a new build of your workflow code at it, and the SDK fails the test if your changes would have produced different decisions. It is the most mature answer in the industry to the “I changed the workflow code, will it break in-flight executions?” question. Flux has no equivalent in 0.56.0.

Temporal Cloud. Managed Temporal removes the cluster-operator burden. You get a namespace, you point your workers at it, you pay per action. For teams that don’t want to operate Cassandra, that’s a real product.

Visibility and search. The visibility API plus Elasticsearch gives you indexed search across workflow types, statuses, and custom search attributes. You can build dashboards and operator queries on top of it without scraping the event log yourself.

Docs and community. Temporal’s documentation is thorough, the community Slack is active, the conference talks are substantive. There is a lot of accumulated knowledge to draw from.

None of this is faint praise. If your situation lines up with these strengths, Temporal is the right tool.

Where Flux differs

The two systems share the core idea — workflow code, persistent event log, replay from checkpoints — and diverge on almost everything else.

Decorator model. Temporal calls them workflows and activities; Flux calls them @workflow and @task. Conceptually they are the same split: the workflow function orchestrates, the task/activity does I/O. The decorator names are different and the option surfaces don’t line up one-to-one, but if you know Temporal’s mental model you know Flux’s.

Determinism rules. Both engines require deterministic workflow bodies. Flux’s rules are not more permissive — you still move time, randomness, and I/O into tasks (see Determinism). What Flux lacks today is the replay-test harness. If you change a workflow body in 0.56.0 and an old in-flight execution resumes against the new code, you find out at replay time, not at test time. Temporal’s replay-history story is genuinely ahead here.

Language. Temporal is multi-language; Flux is Python-only in 0.56.0. The internal abstractions are language-agnostic, and the roadmap leaves room for other languages, but as of July 2026 there is one SDK and one runtime, and they are both Python.

Workers. Temporal workers long-poll task queues — the worker pulls work from the matching service. Flux workers do the opposite: they register with the server, hold open an SSE stream (GET /workers/{name}/connect, see flux/server.py and flux/worker.py), and the server pushes scheduled executions down it. The end result is similar (work reaches a worker), but the direction of the connection is inverted. One practical consequence: a Flux worker behind a NAT or in a constrained network egress-only environment works without extra configuration; the worker dials out, the server never has to reach in.

Storage. Temporal stores history in Cassandra, MySQL, or Postgres, and typically runs Elasticsearch for visibility. Flux stores the event log in Postgres for production or SQLite for development, in a single relational schema (see flux/models.py); large task outputs can be offloaded to a separate object store via the output_storage task option.

Server shape. Temporal Server is four internal services — frontend, history, matching, worker — each able to scale independently. Flux’s server is a single FastAPI process per replica (flux/server.py, no internal service split). You scale Flux horizontally by running more identical replicas behind a load balancer; the Postgres event log is the shared state. Less throughput ceiling, much less operational complexity.

AI and MCP. Temporal does not ship a first-class agent layer or MCP server. Flux does: agents are workflows with an LLM orchestrator (flux/tasks/ai/, flux/agents/), and the MCP server (flux start mcp, flux/mcp_server.py) exposes registered workflows as MCP tools so an external agent can call them. If you are building AI workflows or need workflows to be callable by AI agents, Flux meets you closer to where you’re standing.

Versioning. Temporal uses an explicit GetVersion API inside the workflow body, plus worker build IDs, to coordinate changes against in-flight executions. Flux is simpler and less powerful: each time you register a workflow source, the catalog increments a version counter (flux/catalogs.py, version = existing.version + 1 if existing else 1); runs target a specific version, and the worker compiles that version’s source. There is no in-workflow branching API. Simpler to reason about, less expressive.

Pricing and licensing. Temporal is open source (MIT) with a paid managed offering (Temporal Cloud). Flux is open source; self-hosting is free; there is no managed Flux service today.

Maturity. Temporal has been running large workflow estate in production at well-known companies for years. Flux is at 0.56.0 in July 2026 — much younger software with a much smaller production footprint. That gap is real and matters for risk-averse adopters.

When to use which

Use Temporal when:

• You’re already operating at scale, or you expect to be soon.
• You need workflows authored in multiple languages.
• You want Temporal Cloud to absorb the cluster-operations burden.
• Your team already knows Temporal and ships on it.
• Replay testing of in-flight workflow changes is a hard requirement.

Use Flux when:

• Your platform is Python end-to-end and a single-language engine is a feature, not a constraint.
• You want first-class AI agents and MCP integration without bolting them on.
• You’d rather run a single-process server than a four-service cluster.
• You want a single-binary deployment story (Postgres plus one process).
• You can tolerate software that is younger and has a smaller production track record in exchange for a smaller surface to learn.

Decision dimensions

Read this honestly: Temporal is ahead on languages, replay testing, managed hosting, and production maturity. Flux is ahead on AI integration, deployment simplicity, and Python ergonomics. The rest are tradeoffs, not wins.

Where to read more

• Why durable execution — the pattern Flux and Temporal share.
• System architecture — what’s actually inside a Flux deployment.

Compared against Temporal Cloud and Temporal Server 1.24, as of July 2026. Flux 0.56.0.