Skip to main content

Temporal

Temporal is the durable workflow substrate behind the BPMN engine. This page covers what the Enterprise binary needs from Temporal and how to configure the connection.

When you need Temporal

You useTemporal needed?
DMN evaluation onlyNo
BPMN process executionYes

If you only evaluate DMN decisions and have no BPMN workflows, you can skip Temporal entirely. Set TEMPORAL_HOST_PORT="" explicitly.

Connection

VariableDefaultPurpose
TEMPORAL_HOST_PORTlocalhost:7233Temporal frontend address. Set to "" to disable Temporal entirely.
TEMPORAL_IDENTITYemptyClient identity label shown in the Temporal UI. When empty, the Temporal SDK auto-uses hostname@pid.

Namespaces are auto-provisioned

Each project gets its own Temporal namespace. The engine creates the namespace lazily on the first workflow start for that project — you don't need to pre-create namespaces operator-side.

Authentication and TLS

The connection supports both API-key authentication (Temporal Cloud) and mTLS.

VariableDefaultPurpose
TEMPORAL_API_KEYAPI key string. The Temporal SDK auto-enables TLS when this is set.
TEMPORAL_API_KEY_FILEFile path containing the API key. Takes precedence over TEMPORAL_API_KEY, whitespace is trimmed.
TEMPORAL_TLS_CERT_FILEClient certificate (PEM) for mTLS. Must be paired with TEMPORAL_TLS_KEY_FILE.
TEMPORAL_TLS_KEY_FILEClient private key (PEM) for mTLS.
TEMPORAL_TLS_CA_FILECA bundle to verify the server cert. If empty, the system trust store is used.
TEMPORAL_TLS_SERVER_NAMESNI override. Set when TEMPORAL_HOST_PORT is an IP, or when the server cert CN differs from the host.
TEMPORAL_TLS_INSECURE_SKIP_VERIFYfalseSkip server cert verification. Dev only — leaves the connection vulnerable to MitM.

There is no explicit "Temporal Cloud mode" — Temporal Cloud is supported via TEMPORAL_API_KEY + auto-TLS. For self-hosted Temporal with mTLS, use the TEMPORAL_TLS_* family.

Search attributes

The BPMN engine uses three Temporal search attributes:

AttributeType
BPMNProcessIDKeyword
BPMNProcessVersionInt
BPMNWorkerVersionKeyword

The engine registers these automatically on first tenant namespace provisioning.

Long-running workflows (ContinueAsNew)

Temporal accumulates history events for each workflow and enforces a hard cap of 50,000 events. The engine rotates history via ContinueAsNew before that limit.

VariableDefaultPurpose
TEMPORAL_CAN_ENABLEDtrueEnable automatic ContinueAsNew. Set to false to disable rotation (only safe if no workflow accumulates many events).
TEMPORAL_CAN_HISTORY_THRESHOLD3000Rotate when the workflow's history reaches this many events. Set higher for longer-lived workflows if Temporal can handle the per-workflow cost, lower for safety margin. Setting this to a high value can have performance impacts on the UI.

The threshold defaults to a conservative value to give plenty of headroom below the Temporal hard cap. Raise it if you observe excessive ContinueAsNew churn in your workloads.

gRPC connection tuning

These are escape hatches for unusual networking setups — proxies, load balancers with aggressive idle timeouts, internal payload size policies, and so on. Defaults are appropriate for most deployments.

VariableDefaultPurpose
TEMPORAL_CONN_KEEPALIVE_TIMESDK default (30s)Idle keepalive ping interval. Minimum 10s is enforced by the Temporal SDK.
TEMPORAL_CONN_KEEPALIVE_TIMEOUTSDK default (15s)Keepalive ack wait timeout.
TEMPORAL_CONN_DISABLE_KEEPALIVEfalseDisable keepalive pings entirely.
TEMPORAL_CONN_AUTHORITYgRPC :authority pseudo-header. Use when proxy routing requires a specific authority.
TEMPORAL_CONN_MAX_PAYLOAD_SIZE0 (SDK default, 128 MiB)Max gRPC payload size. Lower it for resource-constrained setups.

Tune KEEPALIVE_* if you see connection drops through a load balancer that idles long-lived gRPC streams.

What goes where

  • DB-side workflow state lives in PostgreSQL (per-tenant schema), separate from Temporal's own workflow state.
  • All operator-facing tuning is via the variables above. The deeper engine and worker tuning lives on the Configuration page.