Limits

View as Markdown

This page lists what can surprise a team that runs Dex in production. Each item links to the page that covers it.

Three defaults need a change before launch.

Closed runs are kept for 7 days. After that the server deletes the run with its Step history, and its Flow ID can start a new Flow.
Public API authentication is off. Any client that reaches the server can call it until you configure an authenticator.
Step retries stop after 4 hours. The Flow then fails, unless the Step has its own retry policy or a failure route.

Run Dex in Production says how to change each one.

Capacity and availability

One active node is the ceiling of a cluster. Dex divides a cluster's Flows and task queues into partitions, which are fixed slices of that state. Today one node owns every partition. So a larger load needs a larger node or a separate cluster. See Grow past one node and Performance.
Failover takes up to the lease duration plus 1 second. The lease is 10 seconds by default. A single-replica setup should use 60 seconds, so it waits up to about a minute after a crash. A graceful shutdown hands over at once. See Lease.
A stalled object store stops the node. A log write that object storage does not accept within 10 seconds stops the active node, and a standby takes over after the lease ends. See When its own dependencies fail.
Failover reruns in-flight Steps. Recovery fails every attempt that a Worker had received, and each one consumes a retry. See Failover and Deploys.
The partition count is fixed at the first start. The first start records cluster.partitionCount, 1024 by default for serve, and a later start with a different count fails. Most clusters keep the default; fewer partitions make each built-in SearchFlows call scan less, so choose the count before the first production start if search speed matters. See Partition count.
Some upgrades stop the cluster. Some server releases need every server process stopped, standbys included, before the new version starts. Upgrades roll forward only. The upgrades page names each such release, so read it before you upgrade. See Upgrades and compatibility.
Beta compatibility runs without a fixed support window. Published APIs, configuration, wire formats, and stored data stay compatible, and a breaking change comes with a migration path. No support period for older releases is promised. See Release status.
Protocol ranges decide compatibility, not version numbers. Dex Server is at 0.1.x and the SDKs are at 1.x. A Worker or Client works with a server when their protocol ranges overlap. See Upgrades and compatibility.

Grow past one node

A cluster has one active node, so its capacity is one node's capacity. Two options work today:

Use a larger node. The benchmark on a 16-vCPU node reaches several times the throughput of a 2-vCPU node. See Performance.
Run separate clusters. Each cluster uses its own object storage prefix, since one prefix holds one cluster. Split Flows between clusters by Flow type, or by a business key such as the tenant. Point each service's Client and Workers at the cluster that owns its Flows.

Each cluster keeps its own Flows, and a Flow stays in the cluster that started it. A SubFlow starts in the same cluster as its parent, and RPCs and Channel messages reach only Flows in the cluster that the Client is connected to. See Install and configure server-zd.

Requests that can repeat

A Step runs at least once. See Idempotency keys.
An ASYNC Step can rerun on a new snapshot. If a server node fails before it saves an ASYNC Step's start, the attempt runs again and can read different Attribute values. See SYNC and ASYNC Steps.
A retried RPC runs again. Each RPC call is a new request, so a client retry can run the handler twice. See RPC.
A repeated Channel publish delivers twice. A PublishToChannel request sent again after a lost response stores the message a second time. Publishing once through request IDs is planned in issue 1519.
A retried StopFlow without a run ID can stop a newer run. Pass the run ID. Doing this for you is planned in issue 1520.

Send a command at most once gives the pattern that drops a repeated command.

Workers and code

An RPC needs a Worker within 10 seconds. If no Worker takes it in that time, the caller gets an Unavailable error. Steps wait in a durable queue instead. See Routing and availability.
A canceled method keeps running. Dex does not stop the code. The method should check for cancellation and return. See Step.
Parallel writers overwrite each other unless they lock. See Locks.
Index slots are limited. With the PostgreSQL search backend, each tenant has 10 Keyword slots and 3 for each other index type, shared by every Flow type. The registry has no delete. See PostgreSQL search.

Release status

Part	Where it stands
Dex	Beta. Published APIs, configuration, wire formats, and stored data stay compatible.
Dex Server (server-zd)	Version 0.1.x. Upgrades roll forward only, and some stop the cluster.
SDKs	Version 1.x, in Go, Python, Java, TypeScript, and Rust.
Dex Cloud	Super Durable runs Dex Server for you. Choose How to Run Dex describes what it operates and what you run.
Compatibility	Decided by protocol ranges, not version numbers. A Worker or Client works with a server when their ranges overlap.

Upgrades and compatibility gives the protocol ranges. Capacity and availability covers upgrades that stop the cluster.

Breaking changes come with a migration path. A breaking change needs an explicit decision first.
Some options are still unsupported. A Flow start delay and a Flow-level retry policy are rejected. An Attribute Store, the optional database that receives copies of chosen Attributes, can only be PostgreSQL. Flow state itself always stays in Dex Server. Unsupported features links each open issue.
Five SDKs, one model. Go, Python, Java, TypeScript, and Rust have the same Flow model.
dexcli dev runs a pinned server. Each dexcli release archive includes the dex-server-zd release it was tested with, and dexcli dev runs that one. Run Locally shows how to install and update it.

License

Dex is source-available under the Sustainable Use License 1.0, which is not an OSI-approved open source license. It lets you run Dex yourself under the terms below.

You may use Dex for your own business operations, whatever your company's size.
You may use Dex as hidden backend infrastructure for a commercial product. This holds when the product's value comes from other features, and its customers do not get direct access to a substantial set of Dex features.
You may charge for consulting, installation, workflow development, and support.
You need a commercial license to white-label, host, or resell Dex, or to build an automation, process, workflow, or software-building platform whose value comes entirely or mostly from Dex.
You may distribute Dex or changes to it only free of charge and for non-commercial purposes.

Dex Skills are under the MIT License. The docs and examples keep their own licenses, and earlier material keeps its original license. The licensing guide explains these terms, and the license text in the repository is what applies. For questions or a commercial license, write to licensing@superdurable.io.

Correctness and Expressiveness: a machine-checked proof of what a crash can change.
Performance
Run Dex in Production
Failover and Deploys