Self-Hosting Temporal Is a Postgres and Private Networking Decision Before Anything Else

Temporal is a durable execution platform for long-running business processes: payment pipelines, subscription billing, order fulfillment, infrastructure provisioning, any workflow that needs to survive crashes, retries, and deployments for seconds or months at a time. The managed service, Temporal Cloud, handles all the server infrastructure and bills per action.

That model is straightforward until downstream services start failing, workflow complexity grows, or execution volume scales, and then every retry, every signal, every timer fire in the bill is a line item. The self-hosting path is well-documented, but what it requires before you can run a single production workflow is a Postgres instance, private internal networking, and compute that matches the long-running nature of the workloads you are orchestrating.

Think about a fintech team running payment reconciliation workflows on Temporal Cloud. Each workflow starts, runs five activities to reconcile transactions across three external APIs, and closes. At a few hundred executions per day, the bill is well within the Essentials plan. Then a third-party API starts returning intermittent 503s. Temporal retries automatically, which is the feature they are paying for. But each retry is a billable action. A workflow that normally costs six actions now costs twelve or eighteen depending on how often the upstream is failing. The bill for that month is three times the estimate. The team looks at self-hosting. What they find is that the infrastructure requirements are not complex, but they are specific: Postgres, private networking, and workers that can run long enough to outlast a deployment cycle.

What Temporal Is and Why Its Infrastructure Demands Are Different

Temporal is an open-source durable execution platform that originated as a fork of Uber’s Cadence. It stores the complete event history of every workflow execution in a database and uses that event history to replay and resume workflows after failures, restarts, or network interruptions. Developers write workflows as ordinary code, and Temporal makes that code resilient without requiring application-level retry logic, state machines, or job queues.

The Temporal Service itself consists of multiple server processes: Frontend (handles all inbound API requests), History (owns workflow state and processing), Matching (manages task queues and Worker routing), and Worker (runs internal Temporal workflows). These processes all depend on a shared database for persistence.

Unlike a stateless web service, the Temporal Service stores durable state that must survive process restarts. That changes the infrastructure requirements considerably: the database is not a cache or a secondary store, it is the authoritative record of every workflow that has ever run on the cluster.

How Temporal Cloud Bills and Where It Compounds

Temporal Cloud’s billing unit is the Action. Actions are billable operations between your application and the Temporal Service, as defined in the official Temporal Cloud pricing documentation. The Essentials plan starts at $100 per month and includes one million Actions. Overage Actions start at $50 per million, with volume discounts at higher tiers.

What Counts as a Billable Action

The following each count as one billable Action per occurrence:

Starting a Workflow execution. Starting an Activity. Retrying an Activity. Sending a Signal to a Workflow. A Timer firing. Starting a Child Workflow.

A simple workflow that starts, runs three Activities, and closes costs four Actions: one for the Workflow start, three for the Activity starts. That is predictable and easy to estimate.

The Retry Problem

Retries are where the cost model becomes harder to reason about. Each retry attempt counts as a billable Action, the same as a first attempt. A workflow with five Activities, where each Activity has an exponential backoff retry policy and a downstream service is experiencing a partial outage, can generate significantly more Actions than its nominal count suggests.

The official Temporal Cloud cost optimization documentation notes that Action consumption should be the primary focus of cost work for most accounts, and specifically recommends ensuring retry policies use an exponential backoff coefficient greater than 1.0 to avoid aggressive, constant-interval retries that compound Action usage during outages.

This is not a flaw in Temporal’s design. Retries are one of the core value propositions. But it means the cost model is sensitive to the reliability of the services your workflows call, which is often outside your control.

At low workflow volumes, these dynamics are minor. At high volumes, or during reliability events in upstream dependencies, they create unpredictable spending.

What Self-Hosting Actually Requires

The official Temporal self-hosted deployment guide is direct about the minimum requirements. The Temporal Service depends on a database. Supported databases are Apache Cassandra, MySQL, and PostgreSQL.

PostgreSQL Is the Right Production Backend

Cassandra support in Temporal has narrowed significantly. Standard Visibility on Cassandra was deprecated in Temporal Server v1.21 and removed in v1.24. The official documentation now recommends migrating from Cassandra to one of the other supported databases for Visibility. PostgreSQL 12 or later is the recommended production backend for new deployments.

From Temporal Server v1.20 onward, PostgreSQL handles Advanced Visibility natively. Advanced Visibility gives you workflow search attributes and filtered queries: the ability to ask the cluster questions like “show me all payment reconciliation workflows in a failed state for merchant ID 4821.” Previously this required running Elasticsearch alongside Postgres. It no longer does.

That simplifies the self-hosted stack considerably. A production Temporal cluster on PostgreSQL 12+ requires the Temporal Server processes and a Postgres instance. No Elasticsearch unless you have specific reasons to add it.

The Postgres instance is the persistence layer for all workflow event history. Schema setup is handled automatically by the Temporal Server on first startup. Connection pooling under load is worth configuring; PgBouncer is the standard choice for high-concurrency deployments.

Network Isolation Is Documented as a Requirement, Not a Recommendation

The official Temporal self-hosted deployment documentation includes a specific warning: “Temporal Hosts Should Not Be Exposed to the Open Internet. In self-hosted deployments, the Temporal Service is a critical control and persistence component and should be secured similarly to a database. Temporal services should run on hosts that are not accessible from the public internet, with network configurations that restrict access to trusted internal networks only.”

This is the Temporal project’s own guidance. Your Temporal Frontend, which handles all API traffic from your Workers and clients, should be on a private internal network. Only Workers and application services that need to submit workflows or query workflow state should have access to it.

That network posture maps naturally to a private cloud deployment. The Temporal Service and Postgres run on a private VLAN. Workers run in the same environment and talk to Temporal over the private network. Nothing in the Temporal topology needs to be on the public internet.

Visibility Store Without Elasticsearch

The default Docker Compose configuration in the Temporal GitHub repository ships with Postgres and an Elasticsearch instance. Many teams inherit that configuration and run Elasticsearch indefinitely because it is in the compose file, not because their Visibility requirements need it.

For most production deployments, Postgres handles all the Visibility queries you need. Elasticsearch adds roughly 1.3GB of resident memory to a minimal deployment based on community benchmarks, and requires its own operational overhead: index management, heap tuning, upgrade cycles. Unless your Visibility query patterns require full-text search or capabilities that PostgreSQL cannot provide, the simpler stack is Postgres alone.

The Compute Profile of a Production Temporal Deployment

Temporal workers run long-lived processes that poll task queues and execute workflow and activity code. They are not stateless HTTP services. A worker process that restarts mid-execution does not lose work, because Temporal replays the event history when the worker reconnects. But the worker process itself needs to run continuously, execute potentially long-running activity code, and handle concurrent task execution.

The Temporal Server processes themselves are not compute-heavy by default. The Frontend, History, Matching, and internal Worker services are all designed to be horizontally scalable and do not require large per-instance resources. A modest VM handles a production Temporal cluster at moderate workflow volumes.

The resource requirements that scale with volume are Postgres I/O (event history writes happen at every workflow step) and Worker compute (activity code runs on workers, so the resource requirements depend entirely on what your activities do). For workflows that call external APIs and do light processing, Workers stay lean. For workflows that do data transformation, document processing, or heavy computation, Worker resource requirements grow with the workload.

OpenMetal’s XL v5 servers at 1TB RAM and 64 dedicated cores give you room to run the full Temporal cluster (Postgres plus Server processes) and a Worker pool on the same hardware, with space to scale. For lighter deployments, a Large v5 at 512GB RAM and 32 cores is sufficient for most production Temporal clusters at moderate workflow volumes. Full hardware specifications are at OpenMetal’s hardware details page.

Where OpenMetal Fits

A self-hosted Temporal cluster needs three things from its infrastructure: a reliable Postgres instance, private internal networking, and long-running compute. OpenMetal’s hosted private cloud provides all three on dedicated hardware.

Postgres runs as a VM inside the private cloud on OpenStack. The Temporal Server processes run as VMs on the same deployment, connected over the private VLAN. Workers run in the same environment. Nothing in the Temporal topology requires a public IP. The 20 Gbps private bandwidth between servers means the communication between Temporal processes and Postgres happens over fast, low-latency internal networking with no egress charges.

Ceph provides the underlying block storage for Postgres volumes. For deployments that use Temporal’s Archival feature to export closed Workflow event histories to object storage for long-term retention or compliance, Ceph’s S3-compatible object storage handles that directly without adding an external service.

OpenMetal’s approximately 45-second cloud deployment gets a Cloud Core running in well under a minute. Postgres and the Temporal Server can be provisioned on top of that as standard VMs. Node scaling in approximately 20 minutes means adding Worker capacity as workflow volume grows does not require a reprovisioning project.

The private networking requirement from Temporal’s official documentation is satisfied by default: OpenMetal customers get isolated VLANs per deployment, and the Temporal Frontend never needs a public address.

For teams building workflows that touch regulated data such as financial records, healthcare data, or customer PII, the single-tenant model also means Temporal’s event history, which contains a record of every workflow execution including inputs and outputs, stays on infrastructure you control.

Temporal Cloud vs. Self-Hosting: The Honest Trade-Off

Temporal Cloud removes the operational overhead of running Postgres, managing Temporal Server upgrades, and handling availability. Three-zone replication is included, automatic failover is built in, and the company that built Temporal maintains the infrastructure. For early-stage teams or organizations without the capacity to own database operations, it is the right starting point.

The trade-off is per-action billing that scales with workflow volume and complexity, and workflow event history that lives in Temporal’s infrastructure rather than yours. Both of those are acceptable trade-offs for many teams. For teams where either constraint is a real problem, self-hosting on dedicated infrastructure is the direct solution.

Who This Makes Sense For

This approach fits teams that:

• Run high-volume workflow workloads where per-action billing at scale makes fixed infrastructure costs more predictable
• Use Temporal for workflows that process sensitive or regulated data where event history must stay inside a controlled environment
• Need workflow infrastructure that sits entirely on a private network, consistent with the official Temporal deployment guidance
• Have complex workflow patterns with significant retry activity where action-based billing is difficult to forecast
• Already operate on OpenMetal for other workloads and want to add Temporal infrastructure on the same private network without external dependencies

This approach adds operational overhead you may not need if:

• You are early in development, evaluating Temporal, or running low workflow volumes where Temporal Cloud billing is predictable and the managed SLA is worth more than the cost savings of self-hosting
• Your team does not have the capacity to own Postgres operations and Temporal Server upgrades
• Your workflows do not touch data that requires infrastructure-level control

The Infrastructure Decision Comes Before the Workflow Design

Self-hosting Temporal is not a complex infrastructure problem. PostgreSQL, private networking, and persistent compute cover the requirements the official documentation sets out. The question of when to make that investment is a function of volume, workflow complexity, and data control requirements. Teams that wait until the billing is already a problem are building infrastructure under pressure. Getting the topology right early is the less stressful path.

Start a proof of concept or contact our team to discuss what a self-hosted Temporal stack looks like on your workload.

Frequently Asked Questions

Does Self-Hosting Temporal Require Running Elasticsearch?

Not anymore. Since Temporal Server v1.20, PostgreSQL 12 or later supports Advanced Visibility natively, which provides workflow search attributes and filtered queries. Elasticsearch was previously required for Advanced Visibility but is no longer necessary for most production deployments. Running Postgres alone simplifies the operational stack considerably.

Which Database Should I Use for a Self-Hosted Temporal Cluster?

PostgreSQL 12 or later is the recommended production backend for new self-hosted deployments. Cassandra’s standard Visibility support was deprecated in Temporal Server v1.21 and removed in v1.24, and the official documentation recommends migrating away from it. MySQL is supported but PostgreSQL has become the community standard for production deployments.

Why Does the Official Temporal Documentation Say Not to Expose the Service to the Internet?

The Temporal Service stores the complete event history and state of all workflow executions. The official deployment guide describes it as a critical control and persistence component that should be secured similarly to a database, running only on hosts accessible from trusted internal networks. In practice this means the Temporal Frontend, which handles all client and Worker API traffic, should be on a private network with access restricted to the services that need it.

What Is a Billable Action in Temporal Cloud?

According to the official Temporal Cloud pricing documentation, billable Actions include starting a Workflow execution, starting an Activity, retrying an Activity, sending a Signal, firing a Timer, and starting a Child Workflow. Each occurrence of these operations counts as one Action regardless of whether it succeeded or failed. Retry attempts on Activities each count as separate Actions.

Can Temporal Run on OpenStack VMs Inside a Private Cloud?

Yes. Temporal has no dependency on bare metal and runs on any compute that can run the Temporal Server binaries or containers. Running it inside an OpenStack-provisioned private cloud on dedicated hardware gives you VM-level isolation for the Temporal processes, Ceph-backed storage for Postgres volumes, private VLAN networking that matches the official deployment guidance, and fixed monthly compute costs.