Server (server-zd)
View as Markdownserver-zd is the Dex Server. It stores every Flow's state and hands Steps and RPCs to Workers. Its only runtime dependency is object storage, such as Amazon S3 or an S3-compatible store.
How it works
server-zd commits every write to object storage before it acknowledges the write. It keeps a local store as a cache. After a restart, a node rebuilds that cache from object storage.
One active process serves a cluster. It holds a lease in object storage, so a second process cannot write at the same time. You can run standby processes that take over when the active process stops.
How it fits with the other components
- Workers and Clients connect to the server's API port. Workers open outbound streams; the server never calls in.
- Dex Web runs as a separate process and reads Flows through the same API.
- dexcli calls the same API. dexcli dev also starts server-zd on your machine.
- server-zd stores one Flow Definition Graph for each Flow type. Workers or dexcli publish it. Each graph records when it was generated. A graph with a later generation time replaces an older one, whatever the upload order. Dex Web reads it to draw the Flow.
- server-zd can write selected Attributes to PostgreSQL. See Keep data after the Flow.
Run it
For local development, run dexcli dev. It starts server-zd with embedded object storage, together with Dex Web.
In production, run dex-server-zd serve with one YAML configuration file. The release publishes binaries and a container image. On Kubernetes, run it as a StatefulSet.
dex-server-zd serve --config /etc/dex-server-zd/config.yaml
To run one production node on local disk without external object storage, run dex-server-zd local. It keeps an embedded object store in its data directory and has no standby.
Reference
The Server reference covers configuration, Kubernetes, high availability, object storage, authentication, Worker dispatch, search, Attribute Store sync, metrics, and upgrades.