Production Integrations
Cadence treats its connections to other software as replaceable interfaces. Persistence, visibility, archival, metrics, serialization, and transport each have more than one implementation, so a cluster runs against systems an organization already operates.
This page covers what Cadence composes with. What a cluster requires to start is in Service dependencies.
Integration summary
Deployment. The four server services are stateless and run under whatever deployment engine an organization already operates. Container images are published for Docker, and the documented production pattern uses an auto-setup image for schema creation and a release-tagged image for steady state. For Kubernetes, the project maintains a Helm chart that deploys the services and, optionally, the Web UI. It needs Kubernetes 1.29 or later and declares six optional subcharts, so a cluster installs whole or points at external datastores. Autoscaling, disruption budget, network policy, and RBAC templates ship with it.
Databases. Workflow history lives in Apache Cassandra, MySQL, or PostgreSQL. CockroachDB and TiDB may offer compatible PostgreSQL or MySQL wire protocols, but Cadence has no dedicated plugin or project CI coverage for them; adopters must validate those combinations.
Search and messaging. Listing workflows by complex predicates uses Elasticsearch, OpenSearch, or Apache Pinot as a visibility store, with Apache Kafka carrying records to the search index.
Observability. The server emits metrics after a reporter is configured. The official Helm chart selects Prometheus by default; static server configuration can select Prometheus, StatsD, or M3. The chart offers a ServiceMonitor for Prometheus Operator and a PodMonitoring resource for Google Cloud Managed Service for Prometheus. Reference Grafana dashboards are published, and the Go SDK carries OpenTracing instrumentation validated against Jaeger.
Security and transport. TLS is configurable on every connection Cadence opens, covering PostgreSQL, MySQL, Cassandra, Elasticsearch, and Kafka. SDK connections to the frontend use mutual TLS. Kafka accepts SASL, managed search endpoints accept AWS request signing, and a proxy sidecar allows cloud IAM authentication instead of stored passwords.
Long-term storage. Closed histories archive to a local filesystem, Amazon S3, S3-compatible storage, or Google Cloud Storage. Large payloads can move to an external blob store through a custom data converter.
Integration details
Deployment and orchestration
Cadence composes with an existing deployment system rather than replacing it. The server services hold no local state, so scheduling, rollout, and restart policy stay with whatever engine an organization already runs. The rest of this section covers the project-maintained Helm chart, which is the packaged path for Kubernetes.
The chart is versioned separately from the server. At chart 1.6.7 the packaged server is v1.4.1 and the Web UI is v4.0.11. The kubeVersion floor of 1.29 comes from the native sidecar init container pattern the database proxy relies on.
Each backing service is declared as a conditional subchart and defaults to off except the primary database, which keeps a default install small while leaving the full stack one flag away. Defaults below come from values.yaml at that tag.
| Subchart | Source | Default | Purpose |
|---|---|---|---|
cassandra | Bitnami | Enabled | Primary persistence |
postgresql | Bitnami | Disabled | Primary persistence |
mysql | Bitnami | Disabled | Primary persistence |
elasticsearch | Bitnami | Disabled | Advanced visibility |
opensearch | OpenSearch project | Disabled | Advanced visibility |
kafka | Bitnami | Disabled | Visibility record transport |
Setting cassandra.enabled=false and supplying connection details points the cluster at an externally managed database, which is the expected production arrangement. Schema initialization runs as a Kubernetes Job with version auto-detection and can be disabled where schemas are managed by a separate migration process.
Server and Web UI containers run as a non-root user with privilege escalation disabled and capabilities dropped. ServiceAccount creation is on by default, while RBAC and NetworkPolicy resources are off so that organizations managing those centrally are not overridden.
Outside Kubernetes, Cadence is distributed as container images on Docker Hub and runs under Docker Compose for local work. Installation and initialization documents the install paths and the commands for each. See Server installation and the Helm codelab for a worked deployment against PostgreSQL and OpenSearch.
Persistence and visibility
Cadence separates execution storage from search. The pluggable backends table in the design principles page lists the current options for each, and Searching workflows covers the difference between basic listing and advanced visibility.
Advanced visibility adds two components. On the write path the history service appends visibility records to a Kafka topic, and the internal worker service consumes that topic and batch-writes into the search index. Reads go from the frontend to the index directly. Both Elasticsearch v7 and OpenSearch 2 are wired in the chart. Pinot is supported by the server as a visibility store but is not part of the chart.
Observability
Cadence emits metrics only when a reporter is configured. The official Helm chart selects Prometheus by default and exposes each service's scrape endpoint on port 9090 unless metrics.port is overridden; server configuration can select Prometheus, StatsD, or M3 instead. Treat 9090 as the chart default rather than a fixed Cadence port. Port 9090 is also the conventional port of the Prometheus server itself.
| Integration | Mechanism | Integration maintained by |
|---|---|---|
| Prometheus | Configurable scrape endpoint; selected by default in the Helm chart | Cadence project |
| Prometheus Operator | ServiceMonitor resource, opt-in | Cadence project |
| Google Cloud Managed Service for Prometheus | PodMonitoring resource, opt-in | Cadence project |
| Grafana | Reference dashboards and Helm setup guide | Cadence project |
| StatsD, M3 | Alternative metrics emitters selected by config | Cadence project |
| OpenTracing, Jaeger | Go and Java SDK tracing support | Cadence project |
| Datadog | Dashboard templates, scraping the Prometheus endpoint | Third party |
Go pprof | Profiling endpoint, opt-in per service | Cadence project |
Metric emission is chosen by configuration rather than compiled in, so an organization standardized on StatsD or M3 does not need a Prometheus deployment. Monitoring covers the signals themselves and Tracing covers the Go interceptor.
Security and transport
TLS configuration follows one shape across every backing service, taking a CA file, an optional client certificate and key for mutual authentication, hostname verification, and a server name override. Certificates mount from Kubernetes Secrets through the chart's shared volume definitions, which lets one bundle cover several services. The chart's TLS guide works through each service in turn.
Authentication to managed cloud services has three documented paths. Elasticsearch and OpenSearch endpoints fronted by AWS accept request signing. A database proxy sidecar handles Google Cloud SQL, including IAM database authentication that removes stored passwords. Kafka accepts SASL credentials.
Cloud provider coverage is uneven at present. Google Cloud has a full deployment guide with four connection modes, while AWS and Azure appear as configuration options without equivalent walkthroughs. Operator-facing authorization is separate from all of this, and the CLI accepts JWT credentials for administrative commands.
Archival and payload storage
History and visibility archival are configured independently, and each selects its own provider due to different storage and search requirements. The filestore provider writes to a mounted volume. s3store covers Amazon S3 and any S3-compatible endpoint, taking an explicit endpoint and a path-style flag for the latter. gstorage targets Google Cloud Storage. See Archival.
Payload handling is an SDK concern rather than a server one. A custom data converter can compress, encrypt, or replace large payloads with a claim check pointing at an external object store, which keeps workflow histories small without the server needing to know the storage system.
SDKs, protocols, and support tiers
| Integration | Notes | Support |
|---|---|---|
| gRPC and Protobuf | Primary API, definitions in cadence-idl | Project maintained |
| Thrift over TChannel | Server still serves it. The Go SDK and Java 3.x clients can use it; Java 4.x and Python are gRPC-only | Project maintained |
| HTTP API | Selected methods over HTTP and JSON, server v1.2.0 and later | Project maintained |
| Go, Java, Python SDKs | Include in-memory test environments and replay tooling | Project maintained |
| TypeScript SDK | In development | Community |
Every maintained SDK ships a test environment that runs workflows in process, and the Go and Java SDKs add replay and shadowing tools that verify code changes against recorded production histories. See the replay and shadowing codelab.
Cadence runs as one cluster or several. Cross-datacenter replication connects clusters for regional failover, and managed Cadence offerings from third parties build on the same open source server and APIs.