Temporal vs Windmill: when each one is the right choice
Choose Temporal when engineers write long-running application logic that must survive restarts, failures and deployments. Choose Windmill when a smaller team needs scripts, internal tools and flows delivered quickly, often in several languages. The decision turns on four questions: who writes the logic, how long workflows run, which license terms apply to your use, and how much operational footprint your team can carry. If your developers need a complete, replayable event history for processes that run for days or months, Temporal is built for that model. If your operators need to turn scripts into flows and internal apps with less infrastructure to own, Windmill fits that work better.
License terms are the first check. Temporal Server is MIT licensed, so embedding it in your products does not bring a copyleft obligation. Windmill source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, and its prebuilt Community Edition images include proprietary code that is free for internal use, while managed services or reselling need a commercial license. Ask legal to map your exact use to those terms before a pilot. On footprint, a self-hosted Temporal Service runs Frontend, History, Matching and Worker services with a persistence store and a separate visibility store, so plan for a cluster. Windmill runs stateless API servers and workers that pull jobs from one PostgreSQL database, which is a smaller set of moving parts.
Identity and audit usually decide the final choice. Self-hosted Temporal uses a default Authorizer that allows every API request until you configure one, so plan mTLS, a ClaimMapper, an Authorizer and OIDC for the Web UI before anyone outside the platform team reaches the cluster. Windmill's SAML, SCIM and audit logs sit in the Enterprise Edition, so if audit logging is mandatory on day one, include that edition's cost in your comparison. Confirm each control against the current documentation and your own environment, starting with the Temporal self-hosted security documentation.
Temporal vs Windmill by scenario: which fits which workload
This table maps common workloads to the platform that fits them better, and states the condition under which each platform wins. Read it as a starting filter: the rows that match your team's skills, licensing position and operating model matter more than any single feature.
| Scenario | Better fit | Why and under what condition |
|---|---|---|
| Long-running business processes with retries and signals | Temporal | Temporal's code-defined workflows keep a complete ordered event history and resume after failures. This wins when the process spans days or longer and engineers own the logic in application code. |
| Order or payment-style services written in Go or Java | Temporal | Temporal ships SDKs for Go and Java, and workflows are ordinary code in those languages. It fits when the service team wants deterministic workflow code under its normal review and test practices, and can run a dedicated Temporal Service. |
| Internal scripts and approval flows built by ops staff | Windmill | Windmill lets operators write scripts in Python, TypeScript, Bash and other languages, then compose them into flows with a UI. It wins when the people building the automation are not application developers and the team wants a script-first workflow. |
| Low-code internal apps on top of scripts | Windmill | Windmill can turn scripts into low-code apps. Temporal has no comparable app-building layer, so teams that need forms and dashboards for operators should check Windmill first. |
| Scheduled jobs that call APIs | Windmill | Windmill's scripts and schedules cover recurring API calls with a lighter setup than a Temporal Service cluster. Temporal can run scheduled workflows, but it is designed for durable application logic, so the simpler job runner often fits better. |
| Teams that must avoid AGPLv3 obligations | Temporal | Temporal Server is MIT licensed. Windmill's core is AGPLv3 when compiled without the enterprise feature flag, and prebuilt Community Edition images include proprietary code. Confirm license obligations with legal counsel before choosing Windmill for a regulated environment. |
| Infrastructure to run and operate | Windmill | Windmill's documented self-hosting uses Docker Compose or Helm with one PostgreSQL database for queueing. Temporal needs Frontend, History, Matching and Worker services plus a persistence store and, for visibility at scale, Elasticsearch or OpenSearch. Teams with limited platform capacity usually find Windmill smaller to operate. |
| Built-in SSO and audit logs without extra licensing | Temporal | Temporal's self-hosted security options include OIDC single sign-on for the Web UI and a Claim Mapper, but the default Authorizer allows all requests until configured. Windmill's SAML, SCIM and audit logs sit in its Enterprise Edition, so confirm the edition you need before deciding. |
How Temporal and Windmill are built and what each means for operations
Temporal and Windmill both run durable, retried work, but they split the job differently. Temporal runs a multi-service server cluster around an event history, while Windmill runs stateless workers against one PostgreSQL queue. The cards below cover the moving parts, the database load, the upgrade path and the deployment options each vendor documents.
Temporal's four service roles
A self-hosted Temporal Service runs Frontend, History, Matching and Worker services, plus separate persistence and visibility stores. Each role can scale and fail on its own, so an operator must watch all four plus both data stores. Check how many pods or hosts your team will run per role and who owns each alert. Ask the vendor or your platform team how the services are sized for your expected workflow volume.
Temporal persistence and visibility stores
Temporal tests persistence on Cassandra, PostgreSQL and MySQL, and treats SQLite as development only. Visibility is a separate store, and Elasticsearch or OpenSearch is recommended once you run more than a few workflow executions. Plan for two data systems to back up, patch and monitor, not one. Confirm which database versions your standards permit before you pick a backend.
Windmill's stateless Rust API and workers
Windmill's backend is written in Rust, with stateless API servers and workers that pull jobs from a PostgreSQL queue. Because the API and workers hold no job state, you can add or replace them without moving data. The trade-off is that PostgreSQL carries the queue, so its connection count, locking and disk latency directly shape job throughput. Ask how the queue is sized and how failed jobs are retried before you commit.
Windmill's nsjail sandboxing
Windmill runs jobs in sandboxes built with nsjail, which limits what a script can reach on the host. This matters when teams let many users submit scripts, or when scripts call internal systems with stored credentials. Sandboxing reduces host exposure but does not replace network segmentation or least-privilege credentials for the worker. Ask your security team to review the worker host profile and which secrets reach each job.
Windmill's worker sizing rule
Windmill's README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM. Treat this as a starting estimate, since heavy scripts, large payloads and external calls change the real footprint. Capacity grows by adding workers, which keeps scaling simple, but every added worker still opens connections to the same queue database. Measure your own job mix before you size a production fleet.
Documented deployment and upgrade paths
Temporal documents Docker Compose, Go binaries, Helm charts that run each service in its own Kubernetes pod, and building the server package into a custom Go binary. Temporal asks operators to upgrade one minor version at a time and to run schema upgrades before server upgrades when release notes require it. Windmill documents Docker Compose and Kubernetes Helm charts, with external PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure. Match the path to the team that will run it and rehearse the upgrade.
Why determinism and replay change how Temporal code is written
Temporal workflows are ordinary code in Go, Java, TypeScript or Python, but Temporal records every step in a complete, ordered event history and uses that history to replay and resume the workflow after a failure. That design is what makes a long-lived process recoverable at the exact point where it stopped. The price is that workflow code must be deterministic: on replay, the same code has to make the same decisions it made the first time. Calls to the clock, random numbers, network reads or changed logic inside a workflow can break replay, so teams move that work into activities and version any change that alters the sequence of steps for workflows already running. Before you adopt Temporal, confirm that your developers will own this discipline and that your test process replays recorded histories against new code before each deployment.
Windmill takes a different route. Scripts and flows run as jobs that workers pull from a PostgreSQL queue, and the platform does not depend on replaying an event history to continue a run. A failed job is retried or rerun, which is simple to operate and easy for a script author to reason about, but it means a half-finished multi-step process is not resumed at an exact internal position in the same way. Ask Windmill for the precise retry and resume behavior of flows in your target version, and test a failure in the middle of a flow before you rely on it for anything that must not repeat a side effect.
The choice follows the shape of the work. Long-running processes such as payment reconciliation, customer onboarding that waits days for a human, or multi-step provisioning, where exact resumption and an audit trail of decisions matter, favor the replayable model and the engineering cost that comes with it. Short jobs, internal automation and scripts that can be safely rerun from the start, where speed of writing matters more than replay guarantees, usually fit Windmill better. A team that mixes both kinds of work should decide which processes need exact resumption before choosing a single platform for them.
Temporal vs Windmill side by side on the capabilities that decide the choice
This table compares Temporal's durable execution model with Windmill's script and flow platform across licensing, programming model, recovery, self-hosting, identity, audit, secrets, managed options and sandboxing. Read each row against your own requirements, since a gap in one column often marks work to confirm with the vendor rather than a missing feature. The main takeaway is that Temporal's advantage lies in deterministic replay of code, while Windmill's lies in running scripts and flows quickly with built-in admin features on its paid tier.
| Capability | Temporal | Windmill |
|---|---|---|
| License | Temporal Server is MIT licensed. Temporal Cloud is a separate paid managed service. | Source compiled without the enterprise feature flag is AGPLv3 and Apache-2.0. Prebuilt Community images include proprietary code, free for internal use only. |
| Programming model and languages | Workflows are written as code in Go, Java, TypeScript and Python using Temporal SDKs. | Scripts in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell and Rust, composed into flows or low-code apps. |
| Determinism and replay | Workflow code must be deterministic. A complete ordered event history is replayed to resume after failures. | Flows run scripts as jobs. Confirm how flow steps resume after a failure and what replay guarantees apply. |
| Persistence and visibility | Tested persistence on Cassandra, PostgreSQL and MySQL. Advanced visibility uses Elasticsearch or OpenSearch at scale. | Workers pull jobs from one PostgreSQL queue. Confirm whether any separate visibility store is needed at your volume. |
| Self-hosting footprint | Frontend, History, Matching and Worker services plus persistence and visibility stores, deployable by Docker Compose, binaries or Helm. | Stateless API servers and workers with external PostgreSQL supported. Docker Compose or Kubernetes Helm charts documented. |
| Identity and SSO | OIDC single sign-on for the Web UI, mTLS, and a ClaimMapper for role mapping. Default noopAuthorizer allows all requests until an Authorizer is configured. | SAML and SCIM on the Enterprise Edition. Confirm which identity options apply to the self-hosted Community Edition. |
| Audit logs and secrets backends | Audit logging not covered in supplied facts. Payload encryption uses custom codecs and a codec server. Confirm audit and external secret options with the vendor. | Audit logs and external secret backends such as Vault and AWS Secrets Manager listed on the Enterprise Edition. |
| Managed option and pricing | Temporal Cloud pay-as-you-go starts at 50 US dollars per million actions (Temporal pricing page), with SAML SSO. | Self-hosted Community Edition is free with limits of 3 workspaces, 50 users and 4 groups. Enterprise starts at 120 US dollars per month (Windmill pricing page). |
| Sandboxing and release cadence | Workflow code runs in your own workers. Confirm the isolation model for untrusted code. Server v1.32.1 released October 8, 2026. | Jobs are sandboxed with nsjail. Latest release v1.840.0 on October 17, 2026, with a frequent cadence. |
What each license and edition allows, and what is paid for
The Temporal Server is licensed under the MIT license, so you can run, modify and redistribute it inside your organization without a license fee for the server itself. Temporal Technologies also sells Temporal Cloud as a separate managed service, and that is where the recurring vendor charge sits. Temporal Cloud pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour, according to the Temporal pricing page.
- Server license: The self-hosted server carries no license fee under MIT, but you pay for the infrastructure and the staff who run the Frontend, History, Matching and Worker services.
- Managed billing: Cloud charges are metered by actions and storage, so volume and retention drive the bill up or down.
- Cloud features: The cloud offering includes SAML SSO and a 99.9% SLA, or 99.99% with high availability, per the same pricing page.
- Self-hosted security: SSO for the Web UI, mTLS and a ClaimMapper are documented for self-hosted deployments, so access controls do not require a paid tier to exist.
- Ongoing cost: Self-hosting shifts recurring spend to your own cloud accounts, database and on-call effort.
Confirm current pricing and SLA terms with Temporal before budgeting, because the figures above come from a dated pricing page.
Windmill's license depends on how you build it. Source compiled without the enterprise feature flag is available under AGPLv3 and Apache-2.0. Prebuilt Community Edition images include some proprietary code that is free for internal use, while managed services or reselling require a commercial license, according to the Windmill GitHub repository.
- AGPLv3 core: The AGPLv3 network clause can require you to offer source for modified versions to users who interact with the software over a network, so internal use and customer-facing use carry different obligations.
- Community limits: The free self-hosted Community Edition is limited to 3 workspaces, 50 users and 4 groups, per the Windmill pricing page.
- Enterprise Edition: The self-hosted Enterprise Edition starts at 120 US dollars per month, priced by developers at 20 US dollars per month each, operators at 10 US dollars per month each and compute units.
- Enterprise features: SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, full Git sync, autoscaling, and Prometheus and OpenTelemetry support sit in the paid tier.
- Legal review: Internal use, customer-facing apps and reselling each fall under different terms, so ask counsel to confirm which license applies to your deployment before go-live.
Before committing, have legal review the AGPLv3 analysis and the Community image terms against your actual use.
What running Temporal or Windmill costs in infrastructure, people and upgrades
Running either platform in your own environment costs more than the software line on a quote, and the largest recurring items differ. A self-hosted Temporal Service runs Frontend, History, Matching and Worker services, plus a persistence store and, for visibility at any real scale, a separate Elasticsearch or OpenSearch cluster. Windmill needs stateless API servers, workers and one PostgreSQL database, with a sizing rule of thumb of one worker per vCPU and 1 to 2 GB of RAM from its README. Ask every bidder to price the full component list for your environments, not a single server count. Infrastructure is paid to your cloud or data center provider, and it recurs for every non-production environment you keep, so a quote should state how many environments it covers.
People costs are where the two diverge most. Temporal workflows are ordinary Go, Java, TypeScript or Python code, so the recurring work is writing deterministic workflow code, testing replay and managing workflow versioning as definitions change while executions are still running. Windmill scripts and flows are closer to standard scripting, which usually shortens maintenance for teams already fluent in Python or TypeScript, but it still needs workspace, permission and secret governance. Upgrades add a fixed cost to Temporal: Temporal Server should move one minor version at a time, to the latest patch of the current minor first, and schema upgrades must run before server upgrades when release notes call for them. Plan for that sequence in each environment, and confirm with the vendor how your chosen Helm chart or Docker Compose release maps to the server image you run.
Paid options change the picture. Temporal Cloud pay-as-you-go pricing starts at 50 US dollars per million actions, with separate active and retained storage rates, and includes SAML SSO, as stated on the Temporal pricing page. Windmill's self-hosted Enterprise Edition starts at $120 per month, priced by developers at $20 per month each, operators at $10 per month each and compute units, and adds SAML, SCIM and audit logs, according to its pricing page as of October 2026. Confirm current figures on each vendor's page before budgeting, because both are listed as of October 2026. One-time costs include initial deployment, SSO and identity wiring, and workflow or script design. Recurring costs include infrastructure, upgrades, licenses or subscriptions, and support. Ask any implementation partner for a written scope covering environments, identity integration, SSO and audit logging, data retention, and upgrade support hours, because projects most often run long on identity wiring and on the first production upgrade.
Moving between Temporal and Windmill: what transfers and what is rebuilt
This sequence shows a team how to move logic in either direction without losing track of in-flight work, and it names which parts carry over as code and which must be rebuilt in the target platform. The output is a cutover plan that a platform owner and a security reviewer can both sign off.
Inventory workflows, scripts and their owners
The platform team lists every Temporal workflow, activity and worker, and every Windmill script, flow and app, with its owner, language, trigger, data stores and downstream callers. Application owners confirm which items are still in use. The step is done when the inventory has one row per item and each row names an owner who has signed off on it.
Classify durable processes against jobs and flows
Each item is sorted into one of two groups. Long-running durable processes depend on replayed event history, signals, timers and deterministic code, so they need a deliberate redesign. Stateless jobs, scheduled scripts and linear flows usually map more directly to Windmill's script and flow model. The output is a classified list in which every durable item has a named redesign owner and every job or flow has a target script or flow.
Plan the drain or cutover for in-flight executions
Temporal workflow histories and Temporal namespaces do not map to Windmill scripts, so running executions cannot be copied across. For each durable process, the team decides whether to let it finish on the existing cluster, drain new starts to the new platform at a set point, or add a compatibility path. The plan records how each execution will be counted and confirmed as complete. Done means every in-flight workflow has a named disposition and a verification query.
Rebuild logic in the target language
Business logic written in Go, Java, TypeScript or Python is carried into Windmill scripts where the language is supported, or kept as a service that Windmill calls over its API. Workflow definitions, retry policies, timers and signal handling are rewritten in Windmill flows or in the calling code. Unit tests and recorded inputs from the Temporal environment are reused where possible. The step is complete when the new scripts pass the same test cases against the same data stores.
Re-wire secrets, identity and audit configuration
Credentials that Temporal workers read from environment variables or external stores are moved into the target platform's secret handling, and the owners confirm access paths. On the Temporal side, namespace roles, ClaimMapper rules, Authorizer configuration and OIDC settings are recorded so that equivalent access and audit controls can be configured in Windmill. Windmill audit logs and SAML or SCIM settings are only available in Enterprise Edition, so the team confirms licensing before cutover. Done means a reviewer can trace who can run, edit and read each script against the written access model.
Move schedules and triggers
Temporal schedules, cron-style starts, webhooks and event-driven triggers are listed with their timezone, overlap and catch-up behavior. Each one is recreated in Windmill, or paused on the old side, with the same expected run times. The team compares run logs for a defined soak period agreed in writing. The step closes when no schedule fires twice and no expected run is missed.
Run both platforms in parallel with a rollback path
Selected workloads run on both systems, with outputs compared against the same source data. Writes are gated so that only one platform acts on a given record at a time. The rollback path is documented: which switch is flipped, which queues are drained, and who approves. The step is complete when parallel outputs match on agreed checks and the rollback has been rehearsed once in a non-production environment.
Retire the old platform and keep the evidence
After cutover, the team decommissions Temporal workers and, when the cluster is no longer needed, its persistence and visibility stores, keeping backups and configuration exports for the retention period that the organization sets. Business logic, API contracts and data stores carry over and remain under version control. The closing check is a signed record listing every item in the inventory, its disposition and its evidence location.
Questions buyers ask before choosing between Temporal and Windmill
How much effort does a self-hosted Temporal Service take to run compared with Windmill?
A self-hosted Temporal Service takes more moving parts to run than Windmill. Temporal runs Frontend, History, Matching and Worker services plus a persistence store and, for advanced visibility, a separate store such as Elasticsearch or OpenSearch. The documented persistence options are Cassandra, PostgreSQL and MySQL, with SQLite for development only. Windmill's stateless API servers and workers pull jobs from a PostgreSQL queue, and its README gives a sizing rule of one worker per vCPU with 1 to 2 GB of RAM. Your effort depends on how many services you operate, how you deploy them (Docker Compose, Go binaries or Helm charts) and whether you run Temporal's services on hosts kept off the public internet. Ask your team to estimate these components against your own environment before comparing staffing.
Can our team self-host either platform without outside help?
Your team can self-host either platform if it has people comfortable with containers, Kubernetes or Linux operations, a managed PostgreSQL or equivalent database and someone who owns upgrades. Temporal additionally requires Go, Java, TypeScript or Python engineers who understand deterministic workflow code, because replay depends on it. Windmill asks more of its operators for scripts and flows than for the platform itself, since developers write Python, TypeScript, Go or Bash jobs that run in its sandbox. Where skills are thin, DeployOpen can plan, implement, harden, back up, upgrade and document either platform inside your infrastructure under a fixed-scope agreement, or provide ongoing support as a retainer.
What drives the cost of an implementation project, and what should a written scope include?
Implementation cost is driven by the number of workflows, the languages and integrations involved, the database and visibility design, identity and secrets integration, hardening, backup and upgrade procedures, and the documentation your auditors will request. DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for each deliverable to be listed with its acceptance criteria, the environments covered, the versions targeted, who operates the platform after handover, and which items are included in a retainer. Platform fees are a separate line: Windmill Enterprise pricing is listed per developer and per operator on its pricing page, and Temporal Cloud pricing is published separately, so confirm which licenses your quote assumes.
Do Windmill's AGPLv3 terms allow internal use, and when do we need legal review?
Windmill source code compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0. Prebuilt Community Edition images include proprietary code that is free for internal use, while managed services or reselling require a commercial license, according to the Windmill repository. Internal use of the Community Edition is therefore generally covered by the repository's stated terms. Legal review becomes necessary when you modify Windmill and offer it to users outside your organization, embed it in a product you sell, or provide it as a hosted service. Temporal's server is MIT licensed, which carries fewer obligations of that kind. Have counsel confirm the position against the exact image and build you deploy, since the image licensing differs from the source licensing.
How is single sign-on configured on Temporal compared with Windmill?
On a self-hosted Temporal Service, OIDC single sign-on is supported for the Web UI, and mTLS is available with separate settings for internode and frontend traffic. A ClaimMapper maps JWT or certificate claims to namespace roles, and an Authorizer plugin enforces access. If no Authorizer is configured, Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control, so this step must be completed before any exposure. Windmill's Enterprise Edition adds SAML and SCIM, and its pricing page lists audit logs in that tier. Confirm with each vendor which identity protocols apply to your deployment and how group mapping is handled, then include those settings in the written scope.
How long does a migration between Temporal and Windmill usually take?
No fixed duration applies, because migration time depends on how many workflows or scripts you move, how much business logic is tied to each platform's programming model, and how much state must be preserved. Temporal workflows are deterministic code whose event history drives replay, so moving them usually means redesigning logic rather than copying files. Windmill scripts and flows are closer to standalone jobs, which can make the conversion more direct for simple processes. Other drivers include identity and secrets integration, the number of environments, testing and cutover planning, and whether in-flight executions must finish on the old platform. Ask for a dependency inventory and a phased plan in the written scope before agreeing to any timeline.
Does Temporal Cloud change the operating picture for a self-hosted team?
Temporal Cloud changes operations by moving the Temporal Service to Temporal Technologies. The published pricing page lists pay-as-you-go pricing that starts at 50 US dollars per million actions, active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, with a 99.9% SLA or 99.99% with high availability, and SAML SSO. Cloud removes the cluster, persistence and visibility components from your own operations, but your workflows, payload handling and data residency decisions still need review. Your team also keeps responsibility for its application code and identity design. Compare the recurring Cloud charges against the staffing and infrastructure costs of a self-hosted cluster, and confirm the terms with Temporal before relying on them.
How DeployOpen works on Temporal vs Windmill
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Temporal vs Windmill, we start with a written scope that fits your workload and control requirements, then build, test and document the platform you choose.
How we scope
- Map which workflows are application logic that needs replayable code and which are scripts and internal flows.
- Define the Temporal Service topology, persistence choice and network boundary, or the Windmill worker and PostgreSQL layout.
- Agree licensing, edition and identity requirements, including SSO, SCIM and audit log needs, before work starts in writing.
How we build
- Deploy the chosen platform with Docker Compose, Helm or Go binaries in your environment, with configuration kept under version control.
- Wire identity and access, including mTLS, OIDC or SAML settings and the Authorizer or permission model, and test them against your roles.
- Test determinism and failure recovery for Temporal workflows, or job isolation and worker sizing for Windmill scripts, with documented results.
How we hand over
- Deliver architecture records, runbooks for upgrades, backups and schema changes, and the operating procedures your team needs.
- Document the licensing position for your use case, including internal-use terms and any commercial license your deployment requires.
- Walk your engineers through operations, then hand over the environment with a written list of open items and owners.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Plan upgrades one minor version at a time, with schema changes applied before server changes where release notes require it.
- Re-run security testing and control evidence reviews after changes, and prepare material for independent assessors without issuing their conclusions.
