Configure Temporal

Temporal Server configuration is found in development.yaml and may contain the following possible sections:

Note: Changing any properties in development.yaml file requires a process restart for changes to take effect.

Note: If you'd like to dig deeper and see how we actually parse this file, see our source code here.


The global section contains process-wide configuration. See below for a minimal configuration (optional parameters are commented out.)

name: temporal
#maxJoinDuration: 30s
#broadcastAddress: ""
#port: 7936

membership - required

The membership section controls the following membership layer parameters:

  • name - required - used to identify other cluster members in the gossip ring. This must be the same for all nodes.
  • maxJoinDuration - The amount of time the service will attempt to join the gossip layer before failing.
  • broadcastAddress - Used as the address that is communicated to remote nodes to connect on.
    • This is generally used when BindOnIP would be the same across several nodes (ie: and for nat traversal scenarios. net.ParseIP controls the supported syntax. Note: Only IPV4 is supported.


  • port - If specified, this will initialize pprof upon process start on the listed port.


The tls section controls the SSL/TLS settings for network communication and contains two subsections, internode and frontend. The internode section governs internal service communication among roles where the frontend governs SDK client communication to the frontend service role.

Each of these subsections contain a server section and a client section. The server contains the following parameters:

  • certFile - The path to the file containing the PEM-encoded public key of the certificate to use.
  • keyFile - The path to the file containing the PEM-encoded private key of the certificate to use.
  • requireClientAuth - boolean - Requires clients to authenticate with a certificate when connecting, otherwise known as mutual TLS.
  • clientCaFiles - A list of paths to files containing the PEM-encoded public key of the Certificate Authorities you wish to trust for client authentication. This value is ignored if requireClientAuth is not enabled.

Below is an example enabling Server TLS (https) between SDKs and the Frontend APIs:

certFile: /path/to/public/cert
keyFile: /path/to/private/cert
serverName: dnsSanInFrontendCertificate

Note, the client section generally needs to be provided to specify an expected DNS SubjectName contained in the presented server certificate via the serverName field; this is needed as Temporal uses IP to IP communication. You can avoid specifying this if your server certificates contain the appropriate IP Subject Alternative Names.

Additionally, the rootCaFiles field needs to be provided when the client's host does not trust the Root CA used by the server. The example below extends the above example to manually specify the Root CA used by the frontend services:

certFile: /path/to/public/cert
keyFile: /path/to/private/cert
serverName: dnsSanInFrontendCertificate
- /path/to/frontend/server/ca

Below is an additional example of a fully secured cluster using mutual TLS for both frontend and internode communication with manually specified Cas:

certFile: /path/to/internode/publicCert
keyFile: /path/to/internode/privCert
requireClientAuth: true
- /path/to/internode/serverCa
serverName: dnsSanInInternodeCertificate
- /path/to/internode/serverCa
certFile: /path/to/frontend/publicCert
keyFile: /path/to/frontend/privCert
requireClientAuth: true
- /path/to/internode/serverCa
- /path/to/sdkClientPool1/ca
- /path/to/sdkClientPool2/ca
serverName: dnsSanInFrontendCertificate
- /path/to/frontend/serverCa

Note: In the case that client authentication is enabled, the internode.server certificate is used as the client certificate among services. This adds the following requirements:

  • The internode.server certificate must be specified on all roles, even for a frontend-only configuration.

  • Internode server certificates must be minted with either no Extended Key Usages or both ServerAuth and ClientAuth EKUs.

  • If your Certificate Authorities are untrusted, such as in the previous example, the internode server Ca will need to be specified in the following places:

    • internode.server.clientCaFiles
    • internode.client.rootCaFiles
    • frontend.server.clientCaFiles


The persistence section holds configuration for the data store / persistence layer. Below is an example minimal specification for a password-secured Cassandra cluster.

defaultStore: default
visibilityStore: visibility
numHistoryShards: 512
hosts: ""
keyspace: "temporal"
user: "username"
password: "password"
hosts: ""
keyspace: "temporal_visibility"

The following top level configuration items are required:

  • numHistoryShards - required - the number of history shards to create when initializing the cluster.
    • Warning: This value is immutable and will be ignored after the first run. Please ensure you set this value appropriately high enough to scale with the worst case peak load for this cluster.
  • defaultStore - required - the name of the data store definition that should be used by the Temporal server.
  • visibilityStore - required - the name of the data store definition that should be used by the Temporal visibility server.
  • datastores - required - contains named data store definitions to be referenced.
    • Each definition is defined with a heading declaring a name (ie: default: and visibility: above), which contains a data store definition.
    • data store definitions must be either cassandra or sql.

A cassandra data store definition can contain the following values:

  • hosts - required - a csv of Cassandra endpoints.
  • port - default: 9042 - Cassandra port used for connection by gocql client.
  • user - Cassandra user used for authentication by gocql client.
  • password - Cassandra password used for authentication by gocql client.
  • keyspace - required - the Cassandra keyspace.
  • datacenter - the data center filter arg for Cassandra.
  • maxConns - the max number of connections to this data store for a single TLS configuration.
  • tls - See TLS below.

A sql data store definition can contain the following values:

  • user - user used for authentication.
  • password - password used for authentication.
  • pluginName - required - SQL database type.
    • Valid values: mysql or postgres.
  • databaseName - required - the name of SQL database to connect to.
  • connectAddr - required - the remote addr of the database.
  • connectProtocol - required - the protocol that goes with the connectAddr
    • Valid values: tcp or unix
  • connectAttributes - a map of key-value attributes to be sent as part of connect data_source_name url.
  • maxConns - the max number of connections to this data store.
  • maxIdleConns - the max number of idle connections to this data store
  • maxConnLifetime - is the maximum time a connection can be alive.
  • numShards - number of storage shards to use for tables in a sharded sql database (Default: 1).
  • tls - See below.

tls sections may contain:

  • enabled - boolean.
  • serverName - name of the server hosting the data store.
  • certFile - path to the cert file.
  • keyFile - path to the key file.
  • caFile - path to the ca file.
  • enableHostVerification - boolean - true to verify the hostname and server cert (like a wildcard for Cassandra cluster). This option is basically the inverse of InSecureSkipVerify. See InSecureSkipVerify in for more info.

Note: certFile and keyFile are optional depending on server config, but both fields must be omitted to avoid using a client certificate.


The log section is optional and contains the following possible values:

  • stdout - boolean - true if the output needs to go to standard out.
  • level - sets the logging level.
    • Valid values - debug, info, warn, error or fatal.
  • outputFile - path to output log file.


clusterMetadata contains all cluster definitions, including those which participate in cross DC.

An example clusterMetadata section:

enableGlobalNamespace: false
failoverVersionIncrement: 10
masterClusterName: "active"
currentClusterName: "active"
enabled: true
initialFailoverVersion: 0
rpcAddress: ""
#type: kafka
  • currentClusterName - required - the name of the current cluster. Warning: This value is immutable and will be ignored after the first run.
  • enableGlobalNamespace - Default: false.
  • replicationConsumerConfig - determines which method to use to consume replication tasks. The type may be either kafka or rpc.
  • failoverVersionIncrement - the increment of each cluster version when failover happens.
  • masterClusterName - the master cluster name, only the master cluster can register/update namespace. All clusters can do namespace failover.
  • clusterInformation - contains a map of cluster names to ClusterInformation definitions. ClusterInformation sections consist of:
    • enabled - boolean
    • initialFailoverVersion
    • rpcAddress - indicate the remote service address (host:port). Host can be DNS name. Use dns:/// prefix to enable round-robin between IP address for DNS name.


The services section contains configuration keyed by service role type. There are four supported service roles:

  • frontend
  • matching
  • worker
  • history

Below is a minimal example of a frontend service definition under services:

grpcPort: 8233
membershipPort: 8933
bindOnLocalHost: true
hostPort: ""
prefix: "temporal_standby"

There are two sections defined under each service heading:

rpc - required

rpc contains settings related to the way a service interacts with other services. The following values are supported:

  • grpcPort is the port on which gRPC will listen.
  • membershipPort - used by the membership listener.
  • bindOnLocalHost - uses localhost as the listener address.
  • bindOnIP - used to bind service on specific ip (eg. - check net.ParseIP for supported syntax, only IPv4 is supported, mutually exclusive with BindOnLocalHost option.
  • disableLogging - disables all logging for rpc.
  • logLevel - the desired log level.

Note: Port values are currently expected to be consistent among role types across all hosts.


metrics contains configuration for the metrics subsystem keyed by provider name. There are three supported providers:

  • statsd
  • prometheus
  • m3

The statsd sections supports the following settings:

  • hostPort - the statsd server host:port.
  • prefix - specific prefix in reporting to statsd.
  • flushInterval - maximum interval for sending packets. (Default 1 second).
  • flushBytes - specifies the maximum UDP packet size you wish to send. (Default 1432 bytes).

Additionally, metrics supports the following non-provider specific settings:

  • tags - the set of key-value pairs to be reported.
  • prefix - sets the prefix to all outgoing metrics.


The kafka section describes the configuration needed to connect to all Kafka clusters and supports the following values:

  • tls - uses the TLS structure as under the persistence section.
  • clusters - map of named ClusterConfig definitions, which describe the configuration for each Kafka cluster. A ClusterConfig definition contains a list of brokers using the configuration value brokers.
  • topics - map of topics to Kafka clusters.
  • temporal-cluster-topics- map of named TopicList definitions.
  • applications - map of named TopicList definitions.

A TopicList definition describes the topic names for each cluster and contains the following required values:

  • topic
  • retryTopic
  • dlqTopic

Below is a sample kafka section:

enabled: false
certFile: ""
keyFile: ""
caFile: ""
cluster: test
cluster: test
cluster: test
cluster: test
cluster: test
cluster: test
topic: active
dlq-topic: active-dlq
topic: standby
dlq-topic: standby-dlq
topic: other
dlq-topic: other-dlq


publicClient is a required section that contains a single value hostPort that is used to specify IPv4 address or DNS name and port to reach a frontend client.


hostPort: "localhost:8933"

Use dns:/// prefix to enable round-robin between IP address for DNS name.