MANAGED DEX ENGINE / MANAGED INFRASTRUCTURE
Run your Dex applications on managed infrastructure while your Workers stay in your environment.
flowServiceAddress := "orders.acme.dex.superdurable.io:443"
client, err := dex.NewClient(registry, cache, dex.ClientOptions{
FlowServiceAddress: flowServiceAddress,
WorkerTarget: &workerTarget,
Credential: credential,
})
if err != nil {
return nil, err
}# Example values — configure these for your Dex application
Dex server orders.acme.dex.superdurable.io:443
API key DEX_ENGINE_API_KEY
# Your application connects with the Dex SDK.
# Dex Workers stay in your environment.SYSTEM ARCHITECTURE
Clients and Workers connect to their managed Dex server. The platform configures and operates the infrastructure behind that server.
↳ Dex API → Dex servers → durable engine (managed)
↳ Dedicated Dex server cluster (optional) ③
Durable engine ↓ Persistence
Dex Workers open a long-lived outbound stream through the edge gateway to their server. No inbound ports are required in your network.
Each Dex application connects to its own managed Dex server through a stable Dex endpoint.
Shared clusters host managed Dex servers by default. A dedicated Dex server cluster is available for organizations that need isolation.
The control plane manages server configuration and lifecycle; the platform runs upgrades, capacity, monitoring and the durable engine behind each server.
MANAGED DEX SERVERS
Managed Dex Engine gives each application its own managed Dex server while keeping the durable engine internal to the platform.
A managed Dex server for each Dex application, with a stable public endpoint.
CLUSTER OPTIONS
Managed Dex servers run on a shared cluster or on an isolated cluster for your organization.
| Capability | Shared cluster | Dedicated cluster |
|---|---|---|
| Tenancy | Multi-tenant platform; server-level authorization | One organization per isolated cluster |
| Databases | Shared cluster persistence | Own databases |
| Rate limits | Per-server limits | Managed by your organization within cluster size |
| Who adjusts limits | Request a raise; platform admin approves | Your organization |
| Approval | Default option | Required |
| Best for | Teams deploying managed Dex servers | Organizations that require cluster and database isolation |
SECURITY & ACCESS
Clients and Workers connect to cloud endpoints over TLS.
Each key is scoped to one Dex server, has an expiry, and can be revoked.
Dex Workers initiate a long-lived pull stream; your network needs no inbound Worker ports.
The platform manages the Dex server lifecycle and durable engine behind it.
An approved dedicated cluster has its own databases for one organization.
PLATFORM OPERATIONS
Dex server and managed durable-engine upgrades
Database schema changes
Shared-cluster capacity and scaling
Infrastructure monitoring and database operations
FAQ
Managed Dex Engine operates your Dex server, the durable engine behind it, platform upgrades, capacity and monitoring.
Use the Dex SDK to connect your application and Workers to the managed Dex server endpoint issued for your application.
You run Workers in any cloud, VPC or on-prem network. Dex Workers connect outbound to their Dex server in pull mode.
Request a higher per-server limit; a platform admin approves requests on shared clusters. Dedicated-cluster organizations manage limits within their cluster size.
See Bring Your Own Cloud for the self-hosted deployment option.
BUILD ON MANAGED DEX ENGINE
Build with Flows, Steps and application-level execution, then connect your application with the Dex SDK.