Temporal security hardening guide for self-hosted clusters

Why Temporal security hardening starts with the default that allows everything

A self-hosted Temporal Service with no Authorizer configured uses the default noopAuthorizer, which allows every API request with no authentication or access control. Hardening is therefore a required step before production data flows, and it belongs in the go-live plan ahead of the first production workflow. Your cluster may already work well, but that proves only that the calls succeed. It does not show who is allowed to make them. The first task is to list every caller, including workers, clients, operators and Web UI users, and to confirm which namespaces each one needs.

This page addresses five layers. The first is mTLS for internode traffic between Temporal services and for frontend client traffic, configured with separate settings for each. The second is a real Authorizer, paired with a ClaimMapper that maps JWT or certificate claims to namespace roles. The third is network isolation, since Temporal services should run on hosts that are not reachable from the public internet and whose access is limited to trusted internal networks. The fourth is payload encryption through custom codecs and a codec server. The fifth is database security for the persistence store and the visibility store. Each layer is covered in its own section, but none works well alone.

The layers depend on one another. The Authorizer can only make decisions about identities it can read, so mTLS certificates or token claims must be set up before role mapping is meaningful. Network isolation reduces who can reach the frontend, but it does not replace authentication for workers and clients that legitimately sit on other networks. The codec server decides who can read payloads in clear text, so its access should match the namespace roles you define. A gap in one layer often weakens the reasoning behind the others, so review them together during planning instead of signing off each one in isolation.

Teams tend to underestimate this work for three reasons. Workflow history contains business data, such as approvals, amounts and customer identifiers, so it needs the same protection as other systems of record. The persistence and visibility stores hold the same history, which means direct database or search index access is also data access. Finally, workers and clients are often owned by different teams and run on different networks, so the caller inventory is larger than the platform team expects. Before go-live, confirm with each owning team which namespaces they use, which network paths they need, and who holds database and codec server credentials.

Which Temporal components and settings carry the security controls

Temporal's security controls sit in several places: the server's TLS and authorization settings, the identity layer that feeds them, the codec that encrypts payloads, and the stores that hold workflow data. Each card names one component, what it protects and what it leaves open on its own. The Temporal deployment docs also say services should run on hosts not reachable from the public internet, so network isolation comes before any of these settings.

Frontend and internode mTLS blocks

Temporal has separate TLS configuration for frontend traffic from SDKs, tools and the Web UI, and for internode traffic between Temporal services. Each block needs its own certificates, CA trust and server name settings, so review both and confirm that internode traffic is never accepted without client certificates. mTLS protects the channel and proves which service or client is calling, but it does not decide what an authenticated caller may do.

Authorizer plugin

The Authorizer decides whether each API call is allowed. If none is configured, self-hosted Temporal uses the noopAuthorizer, which allows every request with no authentication or access control. Configure a real Authorizer before any client connects, then test denied calls in each namespace. It can only enforce decisions on identities that reach it, so authentication and claims must be correct upstream.

ClaimMapper for namespace roles

The ClaimMapper turns identity from JWT claims or client certificates into roles on namespaces, such as read, write or admin. It ties access to the identity provider, so removing a user or group there also removes their namespace roles. It does not verify tokens by itself, and a mis-scoped claim grants the wrong role. Confirm which claims your identity provider issues and how namespace names appear in them.

Custom codec and codec server

Workflow inputs, results and activity payloads are stored in event history, and a custom payload codec can encrypt them in the worker before they leave it. A codec server lets the Web UI and CLI decode payloads for authorized users. Encryption protects payload contents, but workflow IDs, types and timestamps remain visible. A codec server that accepts unauthenticated decode requests can undo the protection, so confirm key management and who can reach it.

OIDC single sign-on for the Web UI

OIDC single sign-on connects the Web UI to your identity provider, so people sign in with their corporate accounts and offboarding happens in one place. It protects interactive access to workflow data in the browser. It does not secure the API used by SDKs, workers and CLI calls, so those paths still need mTLS and an Authorizer. Confirm which groups the Web UI requires and how session lifetimes are set.

Persistence and visibility stores

The persistence store holds workflow state and event history, and the visibility store holds searchable workflow metadata. Both contain business data, so restrict database network access, use database credentials scoped to Temporal, and enable encryption at rest in the database layer. Database controls do not stop an authorized Temporal API caller from reading workflow data. Confirm supported database versions, backup copies and who can administer each store.

Which hardening decisions to make before you change the cluster

This table compares the five hardening decisions that shape a self-hosted Temporal deployment, with the situations where each option fits and what it costs to run afterward. Read each row before touching the cluster, because several choices (certificate lifecycle, Authorizer model, Web UI exposure) are expensive to reverse once workers and operators depend on them.

Decision	Option and when it fits	Operational cost to plan for
Client TLS termination	Terminate at the Temporal frontend when clients connect directly and you want one mTLS trust path. Fits small client counts or teams that already manage frontend certificates.	Certificate rotation touches every SDK client and worker config. Confirm how each language SDK reloads certificates without a restart.
Client TLS termination	Terminate at a gateway when many internal callers already sit behind a managed load balancer or service mesh. Fits organizations with an existing mesh or ingress standard.	Gateway and Temporal trust settings can drift apart. Someone must own both ends, and latency from the extra hop should be measured in your environment.
Certificate issuance and rotation	Use an internal CA with automated issuance for internode and frontend certificates. Fits clusters with many services and a platform team that can run a renewal pipeline.	Renewal automation becomes a production dependency. Expiry alerts, a tested rollback and a documented owner are required before go-live.
Certificate issuance and rotation	Use manually issued certificates with a calendar-based renewal. Fits small, stable clusters with few services and a short list of owners.	Manual renewal is easy to miss. Plan for on-call runbooks, expiry monitoring and periodic rehearsal of a full rotation.
Authorizer model	Decide access by namespace when teams own isolated workflow domains and their own workers. Fits multi-team platforms where namespaces map to business units.	Namespace grants must be reviewed whenever a team or service is added. Access reviews need namespace-level evidence.
Authorizer model	Decide access by role when a small set of operators or services need consistent permissions across namespaces. Fits central platform teams with uniform duties.	Role mappings depend on JWT or certificate claims, so the identity provider becomes part of the authorization path. Plan for claim mapping tests.
Codec server placement	Run the codec server inside the cluster network, reachable only by the Web UI and approved operators. Fits organizations that must keep payload decryption keys in their own boundary.	Someone owns codec availability, since the Web UI and CLI can fail to show payloads when it is down. Include it in on-call rotations.
Codec server placement	Run it on a separate restricted segment with a narrow allowlist of callers. Fits regulated teams that need a documented access boundary around decryption.	Access lists need periodic review, and changes to the allowlist should go through change control with evidence retained.
Web UI exposure	Do not expose the Web UI to user networks at all, and use CLI or private access paths for operators. Fits clusters with strict network segmentation and few human operators.	Operators need a supported access path and a break-glass procedure. Support and incident response take longer without a standing view.
Web UI exposure	Expose the Web UI behind OIDC single sign-on on a restricted network path. Fits teams that need routine visibility into workflows across namespaces.	Identity provider configuration, group mapping and session policy become recurring work. Quarterly access reviews should cover UI roles as well as API roles.

How to harden a self-hosted Temporal cluster in the right order

This sequence moves a self-hosted Temporal cluster from a default that allows every request to one where each network path, client and database account is known, encrypted and authorized. The order matters: the inventory defines the callers, network isolation limits who can reach the cluster, and certificates and authorization then enforce identity. Each step ends with a test you can repeat.

Inventory every network path and client
Before changing any setting, list every way a request reaches the cluster: SDK workers, starter clients, the Web UI, admin tools such as the command-line interface, CI jobs and any service that reads visibility data. For each caller, record the source network, the port it uses, the namespaces it touches and the identity it presents today. Many clusters allow every request by default, so this inventory is often the first time teams see all callers together. The step is done when a signed-off table exists, every later step can test against it, and each caller has a named owner.
Restrict Temporal services to internal networks
Move the Temporal services onto restricted internal networks, as the self-hosted deployment guidance advises, so that none of them is reachable from the public internet. Apply firewall rules that allow only the sources identified in the inventory to reach frontend, history, matching and worker endpoints. Place the persistence and visibility stores on their own segment that accepts connections only from Temporal hosts. Confirm the result from an untrusted network: a port scan or connection attempt to each Temporal endpoint should fail, and approved workers should still connect through their permitted path.
Enable internode mTLS between services
Turn on mutual TLS between Temporal services. Internode settings are configured separately from client-facing traffic, so this change does not yet affect SDK clients. Issue service certificates from an internal certificate authority the team controls, and confirm each service presents a certificate and verifies its peers. Roll the change through a staging cluster first, because a misconfigured service will stop receiving traffic from its peers. Closing check: present an invalid certificate from one service and confirm its peers refuse the handshake and log the failure. Then restore the valid certificate and confirm workflows continue to run.
Enable frontend mTLS for all clients
Enable mTLS on the frontend, the endpoint used by SDK clients, workers, the command-line interface and the Web UI. Each caller needs a certificate signed by the authority the frontend trusts, and workers must receive their certificates and trust roots before enforcement begins. Coordinate this step with the inventory, since any caller missing from it will fail here. Closing check: run a connection test with a client that presents no certificate and confirm it fails at the TLS handshake. Repeat with a valid certificate and confirm the client connects and starts a test workflow in a non-production namespace.
Replace noopAuthorizer with an Authorizer and ClaimMapper
If no Authorizer is configured, the default noopAuthorizer allows every API request with no authentication or access control, so this step closes the largest gap in the cluster. Configure a ClaimMapper that maps identity claims from JWTs or certificates to namespace roles, then configure an Authorizer that enforces those roles on each API call. The design of claims, including how groups in your identity provider map to roles, is covered in the Temporal SSO and authorization guide, so keep that work aligned with this step. Closing check: from an identity that holds no role on a namespace, attempt to start a workflow there and confirm the call is denied. Then confirm the same call succeeds for an identity with the correct role.
Deploy a codec server and SDK codecs
Payload encryption runs through custom codecs. Deploy a codec server inside your network that encodes and decodes workflow payloads, then configure each SDK's data converter to call it for namespaces that hold sensitive data. Apply the same codec configuration to every worker, client and the Web UI, because a component without it will send or display unreadable payloads. Keep encryption keys in your key management system and out of the codec server image and configuration files. Closing check: inspect a stored payload in the database and confirm it is ciphertext, then confirm an authorized user sees decoded data in the Web UI.
Lock down persistence and visibility accounts
Create dedicated database accounts for the persistence and visibility stores. Each account should hold only the schema access and operations the runtime needs, and schema upgrades should run under a separate administrator account. Restrict database connections to the Temporal hosts with network rules, and require encrypted connections where the database engine supports them. Check the persistence and visibility documentation for the store versions Temporal supports for your server release, and confirm them with your database team before rollout. Closing check: attempt a connection with the runtime account from an unapproved host and confirm it is refused, then confirm that schema-changing commands fail under the runtime account.
Rotate credentials and retire open paths
Rotate every certificate, token and database credential that was in use before hardening, then disable the paths that still accept unauthenticated traffic. Remove old client configurations, default administrator access and any direct database connection that bypasses the frontend. Keep the inventory from the first step as the record of what remains, and review it after each Temporal server upgrade, since upgrades should move one minor version at a time. Closing check: rerun the inventory tests from every approved network location and identity, confirm each allowed path maps to an owned, authenticated caller, and confirm that retired paths return denials in the logs.

What drives the effort of Temporal security hardening up or down

This table lists the factors that most change how much work a Temporal hardening project involves, with a way to keep each one contained. Read each row as a lever: the cost of the driver rises with its size, so decisions made early on namespaces, identity and certificates usually matter more than the number of hours spent later. Effort figures are not supplied here, so ask for them in the written scope against your own counts.

Driver	Why it changes effort	How to keep it down
Number of namespaces and teams	Each namespace needs its own authorization roles, rules for who can start, signal or terminate workflows, and review of who holds them.	Scope namespaces early around real ownership boundaries, and avoid creating one per project by default.
Number of workers and clients	Every worker and client needs a certificate or token, a namespace role and a tested connection path. Counts grow quickly across teams.	Group workers by service and identity so that one certificate or service account covers a related set of workers.
Networks and SDK languages in use	Each network segment, language SDK and client library may handle TLS or tokens differently, so each path needs its own test.	Limit the number of SDK languages and standardize one TLS configuration pattern that every team copies.
Existing identity in an OIDC provider or certificate authority	Without an existing identity provider or internal certificate authority, the project must add one, plus user onboarding, rotation and revocation.	Reuse the current OIDC provider for Web UI access and an internal certificate authority that already issues service certificates.
Environments that must mirror production	Development, test and staging need the same TLS, claim mapping and authorization settings, or security tests will not match production.	Keep environments on one shared configuration with only values such as hostnames and secrets changed.
Existing database and certificate tooling	Persistence and visibility stores need their own access controls and encryption settings, and certificate renewal needs a process that can run without manual steps.	Reuse the database platform, secrets manager and certificate automation your organization already operates, and confirm which of them the Temporal persistence and visibility stores support.
Compliance evidence requirements	Assessors often ask for proof of access rules, certificate lifecycle, configuration history and codec key handling, and each item must be collected and kept current.	Agree the evidence list before build starts, and generate configuration and access records from the same source as the deployment.

How to handle certificates, identities and codec keys without exposing them

Temporal security depends on where its credentials live and who can read them. The cards below cover certificates and keys, the identity trust chain, codec keys and the codec server, and database access, because a weakness in any one of them can expose workflow data or let a caller act without authorization.

Certificate and private key placement

Internode and frontend mTLS each need their own certificate chain and private keys, so decide which services hold which keys before deployment. Keep private keys in a secrets store or in mounted secret volumes with restricted read access, and keep them out of container images and version control. Ask your PKI owner how rotation is scheduled, and confirm in the Temporal self-hosted security documentation whether your server version reloads certificates without a restart.

Authorizer and ClaimMapper trust

When no Authorizer is configured, self-hosted Temporal uses the noopAuthorizer, which allows every API request with no access control. Configure a real Authorizer and a ClaimMapper that maps JWT or certificate claims to namespace roles, and document which token issuers and certificate authorities the mapper trusts. Test that a caller with no role, or with a role from another namespace, receives a denial for each namespace it should not reach.

Codec key storage

Payload encryption keys belong in a key management service or vault that the codec server can reach and the Temporal server cannot. Keep them out of Temporal configuration files, environment variables on server hosts and the persistence database, so that a server or database compromise does not expose key material. Ask how keys are versioned, so that encrypted payloads in running and retained workflows can still be decoded after a rotation.

Codec server authentication

The codec server must verify who is asking it to decode before it returns plaintext. Require authenticated requests from the Web UI and CLI origins you approve, and apply identity controls to the codec server that match the controls on the Temporal frontend. Confirm in the self-hosted security documentation which authentication options your codec server and clients support in your version, and record the chosen configuration in the handover.

Codec server access controls

The codec server sees plaintext payloads whenever it decodes, so its access controls matter as much as the encryption it applies. Place it on a restricted network segment, limit which identities can call it, and log each decode request with the caller and namespace. Review who has shell or deployment access to its hosts, because an administrator there can read data the encryption was meant to protect.

Database credentials and scope

Temporal persistence is tested on Cassandra, PostgreSQL and MySQL, and visibility may run on Elasticsearch, OpenSearch or a supported SQL store. Give schema administration, runtime access and visibility access separate database accounts, because schema upgrades need broader rights than the running services. Store each credential in a secrets manager, rotate it on a schedule, and confirm the minimum privileges each account needs with the persistence documentation for your chosen store.

How hardening differs for Docker Compose, Kubernetes and air-gapped clusters

On Docker Compose or Go binaries running on virtual machines, your team controls every host, file and process, so hardening means configuring each service directly. Temporal's deployment guidance says services should run on hosts that cannot be reached from the public internet, with access limited to trusted internal networks. Because the default Authorizer is the noopAuthorizer, which allows every API request, you must set an Authorizer explicitly on each instance.

Network placement: confirm host firewalls or security groups allow frontend, history, matching and worker traffic only from trusted subnets.
Internode and frontend mTLS: set these separately in each service's configuration and distribute the certificate files to every VM.
Authorizer and ClaimMapper: configure identical settings on every instance so that no node accepts unauthenticated requests.
Certificate source: certificates usually come from your internal certificate authority or a managed PKI. Restrict private key file permissions to the service account and keep keys out of compose files stored in source control.
Persistence: use a supported store such as PostgreSQL 13 to 16. SQLite is meant only for development and testing.

Before go-live, confirm with your platform team how certificates are rotated across VMs and which configuration keys your Temporal server version expects.

What to monitor, rotate, upgrade and document after hardening

After go-live, the hardening holds only if someone keeps watching it. These six areas cover the recurring work that keeps authorization, encryption and database controls in place as certificates age, staff change and the server moves to new versions.

Monitor denials and certificate expiry

Authorization denials show who is trying to reach which namespaces, and they exist only after a real Authorizer replaces the default noopAuthorizer, which allows every request. Alert on sustained denial spikes and on frontend, internode and client certificates approaching expiry. Confirm with your Temporal version which logs and metrics expose authorization results, then send those signals to the same alerting path you use for other identity controls.

Rotate certificates and codec keys

Rotate TLS certificates and the keys behind your payload codec on a schedule your security policy sets. Certificate changes affect both internode and frontend settings, so test a rotated certificate in a non-production cluster before it reaches production services, workers and clients. For codec keys, plan how payloads encrypted under the old key stay readable during and after the change, and confirm the key identifier handling in your SDK and codec server documentation.

Run namespace and role access reviews

Review who holds each namespace role, whether it comes from JWT or certificate claims mapped by the ClaimMapper or from a direct assignment. Remove access for people who have left or changed teams, and check the service identities used by workers and automation, which often outlive the people who created them. Record each review with the reviewer, the date and the outcome so the evidence is ready for later assessments.

Audit database accounts

Audit the accounts the Temporal Service uses on its persistence store and, where configured, its visibility store. Confirm each account holds only the privileges its services need, that credentials are rotated and kept out of configuration files, and that no shared or default accounts remain. Supported stores include Cassandra, PostgreSQL and MySQL, so confirm the audit steps against the vendor documentation for the store you run.

Keep hardening configuration in version control

Store the hardening configuration in version control, including server settings, Helm values, Authorizer and ClaimMapper settings, network policies and TLS references, with review on every change. A commit history shows what changed when a rotation or upgrade alters behavior, and it gives you a known-good state to return to. Keep secret values out of the repository and reference them from a secret store.

Re-check security settings on every upgrade

Upgrade Temporal Server one minor version at a time, moving to the latest patch of the current minor first, because backward compatibility is guaranteed only between successive minor versions. Run schema upgrades before server upgrades when the release notes call for them. After each step, re-check authorization, mTLS, codec and database settings against the hardened baseline, and confirm Helm chart compatibility, since chart versions below 0.73.1 do not work with server images 1.30 and later. For the full procedure, see the Temporal upgrades and support topic.

How to test that Temporal security hardening works and fails safely

A hardening change is finished only when tests show that each control rejects what it should and that failures leave the system closed. Start with five negative tests, and write down the expected result for each before anyone runs it. First, a client presenting no certificate, or one signed by an untrusted authority, should be refused during the frontend mTLS handshake. Second, a caller whose identity carries no namespace role should receive a permission denial and no workflow data. Third, workflow payloads read directly from the persistence store should appear as encoded data, and they should stay unreadable until the codec is applied. Fourth, a worker started from a network outside the approved range should fail to connect to the frontend port. Fifth, a database connection with a wrong password, or one that attempts to connect without TLS, should be refused by the store.

Positive tests matter as much as negative ones. Run an approved worker and an authorized client end to end, starting and completing a workflow in each namespace, so that a denial is never mistaken for a broken setup. Then test failure behavior, which is where hardening most often breaks quietly. In staging, issue a short-lived client or worker certificate, let it expire, and observe whether the process stops, logs a clear error and refuses new work. Next, rotate in a valid certificate and confirm the worker reconnects and resumes pending tasks without losing workflow state. How a worker reloads certificates depends on the SDK and the deployment method, so confirm that behavior with the vendor's current documentation and record it in your own runbook.

The codec server is a dependency that can fail independently of Temporal, so test its outage on purpose. Stop the codec endpoint, then start a workflow that carries a payload. Confirm that workers and the Web UI report errors instead of falling back to plaintext, and that no unencrypted payload reaches the store during the outage. Restore the codec and check that tasks retried during the outage complete. Also review which errors your workers classify as retryable and which ones fail the workflow. If a short codec outage permanently fails workflows, that is a design problem to fix before go-live. Record how many workflows reached a failed state during the test, why they failed and how long recovery took in your own environment.

Run the same suite in staging before production, and keep staging close enough to production that the results carry over. Use the same certificate authority chain, the same ClaimMapper and Authorizer configuration, the same network segmentation, the same codec server setup and the same database TLS settings. A permissive staging firewall or a test certificate authority trusted by production clients will make passing results meaningless. Re-run the suite after every server upgrade, Helm chart change, certificate authority rotation and authorization policy change, and keep dated results in your compliance readiness file. Independent auditors decide whether that evidence is sufficient. DeployOpen can prepare the controls, test cases and records for their review.

What buyers ask about Temporal security hardening before hiring help

How much does Temporal security hardening cost?

The cost depends on scope, and a fixed price follows from a written scope rather than a standard rate. The main drivers are the number of clusters and environments, whether mTLS already exists for any traffic, how many namespaces need role mapping, which identity provider is used, whether a codec server is needed, and how many application teams must change code. The one-time costs are the planning, configuration, testing and documentation of the hardening work, plus the internal staff time it consumes. Recurring costs include certificate rotation, patching, access reviews and any ongoing support retainer. When requesting a quote, ask for a scope that lists each cluster, namespace, identity source, certificate authority, database, codec change and the deliverables expected at the end.

How long does a Temporal hardening project take?

The duration depends on scope, so no single timeline applies to every Temporal cluster. The largest effects come from the number of clusters, the number of application teams affected by codec or certificate changes, and how quickly the certificate authority, network and database owners can approve work. Environments that already have documented change windows and a working identity provider usually move faster than those that need new processes first. Staged rollouts also add time, because each step needs verification before the next one. Ask any provider for a timeline tied to a written scope, with named dependencies on your side, and confirm which dates depend on approvals that your organization controls.

What does our team need to provide for Temporal hardening?

Most of the work needs access and decisions from several owners, not only the platform team. Expect to provide:

Certificate authority access to issue and rotate certificates for internode and frontend traffic
Network changes to restrict Temporal services to trusted internal networks
Database owners to create least-privilege accounts and review persistence access
Application teams to update clients and workers for TLS and any payload codec changes
Identity administrators for the OIDC or JWT settings used by the Web UI and the ClaimMapper

Also plan for change windows, a test environment that matches production and a named person who approves rollback. Ask the provider to list these dependencies in writing before work starts.

Can our own engineers harden a self-hosted Temporal cluster?

Yes, a capable internal team can harden a self-hosted cluster, because Temporal's self-hosted security documentation describes the settings involved, including mTLS, a ClaimMapper, an Authorizer plugin, OIDC for the Web UI and custom codecs. The harder part is the surrounding work: designing namespace roles that match real ownership, running a certificate lifecycle, testing that workers still connect, and keeping the configuration aligned with each server upgrade. Internal teams that already run public key infrastructure, identity services and database administration usually carry less risk. Teams without those skills often use a fixed-scope partner for the first pass and keep the documented configuration so that their own engineers can maintain it afterward.

Will hardening a Temporal cluster break running workflows?

It can, if the changes are applied without a sequence. The most common breakages come from clients or workers that lack valid certificates, an Authorizer that denies calls from existing workers, and rolling restarts that mix old and new settings. Payload encryption adds another risk, because workers and the codec server must decode existing payloads consistently with the codec in use. A safer approach is to test each change in a non-production environment, apply it to one namespace first, confirm that workers reconnect and that workflow histories decode in the Web UI, and keep a rollback path for each step. No provider can guarantee that running workflows will be unaffected, so ask for the test plan and rollback steps in the written scope.

Does Temporal Cloud take over security hardening responsibilities?

Temporal Cloud reduces the operating work of running the service, but it does not remove every hardening decision. Your team still decides how identities map to namespace access, how workers authenticate, how payloads are encrypted and how network paths to Temporal are controlled. Temporal's pricing page lists SAML SSO for its pay-as-you-go plan, so confirm which features your chosen plan includes. Support also differs by tier. The Business add-on starts at 500 US dollars per month with a 2-hour P0 response during business hours, while Enterprise and Mission Critical are quoted by sales, offer 30-minute or 15-minute P0 response around the clock and include SCIM. Compare these terms with your own response obligations before deciding.

Which Temporal hardening steps should come first?

Start with the controls that stop unauthenticated access, then add identity and payload protection. A practical order for a self-hosted cluster is:

Network isolation so Temporal services run only on trusted internal networks
mTLS for internode traffic, then for frontend and client traffic
An Authorizer and ClaimMapper so requests map to namespace roles, since the default noopAuthorizer allows every API request
Least-privilege database accounts for the persistence and visibility stores
A codec server and custom codecs for payload encryption, rolled out namespace by namespace
OIDC for the Web UI and regular access reviews

Verify each step before moving on, and record the configuration so upgrades do not reopen earlier gaps.

What does DeployOpen deliver for a Temporal hardening engagement?

DeployOpen works under fixed-scope engagements, so the scope, deliverables and timeline are agreed in writing before work starts. For Temporal, the work typically covers configuring mTLS, the Authorizer and ClaimMapper, network isolation, codec and codec server setup where agreed, and database access controls within your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. DeployOpen documents the configuration and prepares the evidence your teams need for internal reviews or compliance assessments. It does not issue audit reports, attestations or certifications, because independent auditors and certification bodies perform those assessments. Ongoing support, upgrades and continuous testing are available as retainers if your team wants help after go-live.

How DeployOpen scopes, hardens and hands over Temporal security work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Temporal security hardening follows the same written-scope approach. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Temporal frontend, internode and Web UI endpoint, and record which clients and workers reach each one.
Confirm the self-hosted deployment method, server version and persistence and visibility stores before choosing hardening controls.
Agree in writing whether the work covers mTLS, Authorizer design, network isolation, codec server and database hardening.

How we build

Replace the default noopAuthorizer with a defined Authorizer and ClaimMapper that maps identity claims to namespace roles.
Enable separate mTLS settings for internode and frontend traffic, with certificate issuance and rotation documented for the client's PKI.
Place Temporal services on hosts not reachable from the public internet, and restrict database and visibility access to trusted networks.

How we hand over

Deliver configuration as code, with a record of each control, its owner and how it was verified in the client's environment.
Run verification tests for unauthenticated access, certificate rejection, namespace role boundaries and payload encryption through the codec server.
Document operating procedures for certificate rotation, Authorizer changes, version upgrades and access reviews for the client's team.

How we support

Review hardening settings when the client moves to a new Temporal Server minor version, following the one-minor-at-a-time upgrade path.
Maintain evidence for compliance readiness work, while noting that independent auditors and certification bodies issue any attestation.
Offer ongoing support, upgrades and continuous testing as a retainer, with scope agreed in writing.