# Temporal Self Hosted: Setup and Costs (2026 Guide) By James Okafor · 2026-10-27 · Source: https://www.activepieces.com/blog/temporal-self-hosted-setup-and-costs-2026-guide --- Self-hosting Temporal means you run the Temporal Server, the database behind it and the workers that execute your code, and the licence costs nothing while the operating work doesn't, a trade-off familiar to anyone who has also self-hosted an automation tool like [Activepieces](https://www.activepieces.com). Self-hosted Temporal is the practice of running the open-source Temporal Server yourself, along with its persistence database and your workers, and taking responsibility for its scaling, monitoring, backups and version upgrades rather than buying them as a managed service. According to its repository, the server is open source under the MIT licence, so no one bills you for it. **Your team carries the pager instead**. That's the whole trade. A free licence tells you what you won't pay Temporal. It says nothing about what you'll pay in engineer hours, which is why the choice is between owning the stack and renting it from Temporal Cloud. **When you self-host, every layer below is yours**. ## Temporal self-hosted means running the server yourself - The Temporal Server services, which you deploy, scale and upgrade. - The persistence database that holds workflow state, which you provision, back up and patch. - Optional Elasticsearch visibility, which you add if you want to search and filter workflows, and which then becomes another cluster you own. - Your own workers, which run your workflow and activity code and which you own in every deployment, self-hosted or not. ![Server services, database cylinder and Elasticsearch box connected by lines](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/aad24cbc-1be1-4ac9-878b-6fca177fe960/temporal-self-hosted-setup-and-costs-2026-guide-fcc35898.webp) With Temporal Cloud, the first three move to Temporal. The last one stays with you, because your code always runs on your infrastructure. The rest of this article asks what it costs to keep the first three in-house. We checked the product facts here on 27 October 2026 against [Temporal](https://temporal.io/pricing)'s own pages and its repository. Where a claim depends on a plan, a limit or a price, treat Temporal's current pages as the authority, since they can change after that date. If you also need workflow automation without running a cluster, such as when you are evaluating [Activepieces](https://www.activepieces.com), compare on the same requirements. ## How a self-hosted Temporal cluster works Four server services backed by a database you run, an optional search index, and worker processes that hold your code: that is a self-hosted Temporal cluster, which means you're responsible for infrastructure and operations. The only part you don't operate on Temporal Cloud is the server box and its stores. ### The four services The Frontend is the gateway: every client and worker call enters through it, and it handles routing and rate limiting. The History service owns each workflow's event history and state, so it's the component that makes durable execution durable. ![Clients enter Frontend gateway, which connects to History service holding event cards](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/5f48d1d3-77b0-46fc-a036-1c36e5211bcf/temporal-self-hosted-setup-and-costs-2026-guide-24be5a23.webp) The Matching service hands tasks from queues to workers that are polling for them. The Worker service is Temporal's own internal background worker, which runs system workflows such as replication and archival chores. You can run all four in one process while learning, but in production they scale separately. History is usually the one that needs the most attention, because it carries the write load. ### Choosing databases for self-hosted Temporal persistence According to Temporal's documentation, Cassandra, MySQL and PostgreSQL are the supported persistence stores. Pick one and treat it as the heart of the system. Every workflow state transition is written there, so its backups, failover and capacity planning are now your responsibility, and losing it means losing workflow state. Elasticsearch is optional for visibility, the search and filtering over workflows. Without it you rely on the database for basic listing. With it you get richer queries, along with another cluster to patch and size. ### Workers are always yours Whether you self-host the server or use Temporal Cloud, workers run on your infrastructure. They are the processes that run your workflow and activity code: they poll the Frontend, execute your code and report results. Cloud takes over the server, database and upgrades, but it never takes over your workers. ## Where teams use self-hosted Temporal in production Teams self-host Temporal for the workflows that must survive failure: payments, orchestration, provisioning and pipelines. They do it when residency, network isolation, cost or control rule out a hosted service. That's the work you take on running the cluster for. Across Temporal's docs and case studies, four patterns cluster, and all four share one trait: a half-finished run is expensive, so durable state and retries are worth the operating burden. - Payments and order flows: charging a card, reserving stock and sending a confirmation, where a processor timeout must retry without charging twice. - Long-running orchestration: an onboarding or approval process that waits days for a human, and must resume exactly where it stopped after a deploy. - Infrastructure provisioning: creating a network, a database and DNS records in sequence, with cleanup steps if the third one fails. - Data pipelines: multi-stage jobs that pull, transform and load, and resume from the failed stage instead of restarting. Rarely are features the reason teams self-host. The reasons are constraints you can't negotiate with a vendor. - Data residency: a healthcare team that must keep workflow payloads inside one country's regions. - Air-gapped networks: a defence or industrial site where nothing may reach the public internet, so a hosted service is unreachable by design. - Cost at volume: a high-throughput pipeline where usage-based pricing would outgrow the cost of the machines and the engineers who run them. - Control: a platform team that wants to pin server versions, schedule upgrades around its own release freeze and tune the database. ## What self-hosting Temporal costs and requires Roughly **$480 to $790 a month** in infrastructure, before anyone is paid to run it, and nothing in licence fees: that is what self-hosting costs. ### Self-hosted: licence, infrastructure, people Because the server is open source, **the licence line is zero**. The bill arrives as a database, a cluster and someone on call. For a small self-hosted cluster, [Automation Atlas](https://automationatlas.io/answers/temporal-self-hosted-pricing-2026/) puts the cost at $480 to $790 a month. That excludes staff time, so the true figure is higher, and the person who patches the database and rehearses upgrades is the cost that never shows on an invoice. ### Temporal Cloud: published pricing and plans Even the dearer plan sits below the top of the self-hosted range. Per Automation Atlas, Cloud Essentials is $100 a month and Cloud Business is $500, though Pay-As-You-Go itself has no base monthly fee. Usage is billed separately. ![Temporal Cloud usage bill at different monthly Action volumes](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/a1835327-f635-4a89-86cc-66f00ee0f156/temporal-self-hosted-setup-and-costs-2026-guide-5cfc62d3.svg "Source: Temporal") Usage is counted in Actions, the billable steps Temporal records as your workflows run. Starting a workflow, running an activity, sending a signal and firing a timer each count, and Temporal's pricing page lists the exact set. As a rough scale, a multi-step workflow with a handful of activities uses on the order of ten Actions once you count its start, its timers and a few retries. Multiply that by the workflows you start in a month to estimate your own volume. As published on 27 October 2026, Temporal's pricing page works out to $50 a month at 1M Actions, $500 at 10M, $2,500 at 50M, $5,000 at 100M and $25,000 at 500M. At 10M Actions a month, usage alone matches the cheapest self-hosted bill, which is where the crossover begins. At 500M, the usage fee is the argument for running it yourself. Set side by side in the table, the six requirements show that Cloud replaces the labour rows (staffing, upgrades, support) with a fee, while the licence row never differed. | Requirement | Self-hosted open source | Temporal Cloud (as published 27 October 2026) | |---|---|---| | Licence | Open source, no fee | Usage-based, $50 per 1M Actions | | Infrastructure | $480–$790 a month, excluding staff | Run by Temporal; Essentials $100, Business $500 a month | | Staffing | You own the database and cluster | Temporal operates them | | Upgrades | You plan, test and apply them | Temporal applies them | | SSO | You connect your own identity provider | Configured on the managed service | | Support | Community plus your own on-call | Vendor support included with the plan | viz type=distribution title="Monthly cost of Temporal Cloud plans and a small self-hosted cluster" unit="$ per month" source="Automation Atlas - https://automationatlas.io/answers/temporal-self-hosted-pricing-2026/" target="480" benchmark="Self-hosted low estimate"00 for Cloud Essentials and $500 for Business." Cloud Essentials: 100 Cloud Business: 500 Self-hosted low: 480 Self-hosted high: 790 ![Activepieces pricing page displaying four subscription tiers with features and costs.](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/841ec84e-02e4-4761-aca2-e92f6d457f41/self-host-mistral-ai-enterprise-deployment-guide-c7d7dca9.webp) The two charts that follow turn these rows into monthly cost and show where usage tips the balance. ## Mistakes that make self-hosted Temporal fail **The cost charts assume the cluster stays up**. In practice it goes down for a handful of avoidable reasons, each with a cheap fix. Because it works, teams promote the bundled dev server (`temporal server start-dev`) and then lose workflow state on the first restart. It is built for a laptop: one process, local storage, no redundancy. ![Paper model bridge with a heavy truck about to cross](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/7dd31cfc-6b10-49cc-b9fb-a060703be130/temporal-self-hosted-setup-and-costs-2026-guide-7e4ce283.webp) Run the real services (frontend, history, matching, worker) against a persistent database, and keep the dev server for local tests only. ### Picking shard count and database casually **The history shard count is set when the cluster is created, and per the documentation you can't change it afterwards without rebuilding.** A low guess caps your throughput for the life of that cluster. Load-test with realistic workflow volume and choose generously before the first production workflow starts. Next comes the database. Every workflow event lands there, so a shared or undersized instance becomes your ceiling. Give Temporal a dedicated database with backups and tested failover. It also benefits from an advanced visibility store: without it, filtering and searching workflows is badly limited, and operators end up debugging blind. Configure it at install, not during an incident. ### Non-deterministic workflow code breaks self-hosted Temporal Because Temporal recovers by replaying workflow history against your code, the code must make the same decisions every time. Calling the system clock, random numbers or the network directly inside workflow code breaks replay. Use the SDK's workflow-safe time and random functions, and put side effects in activities. Before each deploy, replay recorded histories against the new build, and use the SDK's versioning for changes to running workflows. ### Skipping upgrades and monitoring on self-hosted Temporal When you fall several releases behind, a routine upgrade turns into a risky migration. Upgrade one minor version at a time, apply schema updates first, and read the release notes. Export the server and SDK metrics to your monitoring system and alert on persistence latency and task queue backlog. Without them, you learn about trouble from your users. ## When Temporal self-hosting is the wrong tool If nobody on your team can own the database, the cluster and the upgrades, self-hosting Temporal is the wrong tool. It's also wrong when the job is wiring business apps rather than writing durable code. The monitoring gaps above are what that ownership costs. ### Choose by who writes the workflows Start with ops capacity. If you have no one to carry a pager for the persistence layer, pay Temporal Cloud to run it; you keep writing workflows in code and hand off the cluster. Self-host only when compliance forces the data to stay inside your boundary, or when your scale makes running it yourself worth the staff time. Either reason needs a named owner before you deploy, not after the first stalled workflow. Next, ask who authors the logic. Temporal expects developers writing code. If the people building automations are operations or marketing staff connecting a CRM to a spreadsheet, you're buying durability they will never use. ### Where Activepieces fits, and where it does not Activepieces lets those teams connect business apps through a visual builder, on your own servers or on its managed cloud. Its core is MIT-licensed, and the open source monorepo holds 744 integrations, roughly 60% of them contributed by the community, so most integrations rely on community volunteers for maintenance. Its air-gapped self-hosted build is not a cut-down edition: the SSO, SCIM, custom RBAC, audit logs, release management and secret managers listed in its docs for that build are the same ones the managed cloud carries, and MoneyGram and Moneypenny run Activepieces in production. This table sets it beside both Temporal options; read the pricing column as pointers to each vendor's own pricing page, which is where to confirm current terms. | | Audience | Authoring | Hosting | Pricing | |---|---|---|---|---| | Temporal self-hosted | Engineering teams | Code | You run the database and cluster | No licence fee; you pay for infrastructure and people | | Temporal Cloud | Engineering teams without ops capacity | Code | Run by Temporal | Paid service, see Temporal's pricing page | | Activepieces | Teams connecting business apps | Visual builder | Self-hosted or its cloud | Open source to self-host; cloud plans on its pricing page | For long-running, code-defined business logic with strict retry and versioning needs, it doesn't replace Temporal. For app-to-app glue, though, it removes the need to run a Temporal cluster at all. ## Your first week with self-hosted Temporal ### Deciding who runs your self-hosted Temporal cluster If you do need a Temporal cluster, **spend Monday deciding who runs it**, then prove that choice on a staging copy before production sees a single workflow. 1. Name the person who gets paged when the database fills up. If nobody volunteers, the decision is made: pay for Cloud. 2. Stand up staging on PostgreSQL, using the official Helm chart if production will be Kubernetes, or Docker Compose if you only need a quick local copy. Staging that differs from production hides the problems you came to find. 3. Push your real workflow shapes at staging until something slows down, and note which component slows first. That tells you where to size up. 4. Scrape the server metrics and alert on database health and workflow task latency. 5. Rehearse one version upgrade on staging and record every command. The first real upgrade then follows a script, not memory. 6. Compare Cloud's current terms against your measured effort from steps two to five. The comparison now rests on what you saw, not on a guess. Self-hosted, you own the database, the server services, scaling, backups and every upgrade. On Cloud, Temporal operates the cluster and you keep only your workers and your workflow code. ## Frequently asked questions Is self-hosted Temporal really free? Free, as far as the licence goes: the server is open source, so you pay nothing to run it. What you pay for is everything around it, meaning the database, the cluster, upgrades and whoever is on call when it stalls. Can I move from self-hosted Temporal to Temporal Cloud later? Yes, because your workflow and activity code stays yours and workers connect to whichever endpoint you point them at. Running executions don't move on their own, so plan a cutover: let in-flight workflows drain on the old cluster while new ones start on Cloud. Rehearse it in a test namespace before you rely on it. ### Does self-hosted Temporal include SSO? Partly, and you build the rest. The Web UI can be configured for OIDC login, and the server accepts a custom authorizer and claim mapper for access control. You wire, test and maintain all of it yourself. On Cloud, SSO is a managed setting, and the plan that includes it is on Temporal's own pricing page, which is where to check it. How many engineers does it take to run Temporal? Fewer than the cluster's complexity suggests, but never one. A single owner means every upgrade and every 3 a.m. incident rests on one person who may leave or be asleep. Aim for at least two engineers who understand the database, the server services and the upgrade path well enough to cover each other. Which database should I use for self-hosted Temporal? Use PostgreSQL or MySQL, whichever your team already backs up, monitors and restores without thinking. Temporal also supports Cassandra, which suits very large scale, but it adds a system Most small teams have no experience running. This text has no competitor compliment, superlative, number, or product name to change, and it looks cut off after "running." If you paste the full sentence, I'll rewrite it as you described. Pick the database you can recover at speed, not the one that benchmarks best. ## Related reading - [Self-Hosted AI Workflow Automation: A 2026 Guide](https://www.activepieces.com/blog/self-hosted-ai-workflow-automation-a-2026-guide) - [Self-Hosted vs Cloud Security Automation for 2026](https://www.activepieces.com/blog/self-hosted-vs-cloud-security-automation-for-2026) - [Self-Hosted Automation Platform: Best Options for 2026](https://www.activepieces.com/blog/self-hosted-automation-platform-best-options-for-2026) ## References - [Automation Atlas](https://automationatlas.io/answers/temporal-self-hosted-pricing-2026/) - [Temporal](https://temporal.io/pricing)