Windmill vs Temporal

Backend engineering teams building distributed systems where survival across crashes is the primary requirement: payment flows, sagas, multi-step user signup, long-running provisioning, AI agent runtimes. Strong adoption in Go and Java shops historically (ex-Cadence DNA), with TypeScript and Python now first-class.

Long-running multi-step application logic where each step is itself substantive (an HTTP call, a payment API, a file transfer). Less suited to high-volume short tasks where the per-step event-history overhead dominates.

First-party SDKs for TypeScript, Python, Go, Java, .NET, PHP and Ruby. Workflows and activities are written in the SDK host language; activities are the escape hatch for any other language via process spawn.

Workflows and activities are written using one of seven SDKs (TypeScript, Python, Go, Java, .NET, PHP, Ruby), each with its own decorator or annotation pattern (e.g. @workflow.defn + @activity.defn in Python). The strict workflow / activity split: workflows must be deterministic and orchestrate; activities run normal code with side effects. Determinism is sandboxed in TS and Python, convention-only in Go and Java.

Event sourcing plus deterministic replay. Every workflow decision (schedule activity, start timer, send signal) is recorded as an event in an immutable event history in Postgres, MySQL or Cassandra. When the workflow resumes after a crash, the SDK replays the workflow function from the beginning, returning each previous step's result from the event history until it reaches the next decision.

This gives true durable execution (workflows can run for months and survive any crash) and a complete audit trail. The trade-off: workflow code must be deterministic (no Math.random(), no direct clock access, no I/O) and a 3-step workflow generates around 23 events. Activities run in normal code and are unrestricted.

Standard tooling for whichever SDK language you pick: VS Code or any IDE, language-native type-checking and linting, and the Temporal CLI plus a local temporal server start-dev for an in-memory dev cluster. Workflows can be unit-tested with the SDK test framework that mocks time and activities.

No first-class resource concept. Activities receive typed inputs and read credentials from environment variables, the worker process configuration or whatever secret manager you wire in. Temporal Cloud has Namespaces with API key auth, but connection details for downstream services are handled by your code, not the platform.

Workflow and activity code lives in a normal repo per SDK language. Workers are deployed as your service (Docker, Kubernetes, your platform of choice). Namespaces, schedules and search-attribute schemas are configured in Temporal Cloud or via the CLI; they are not automatically versioned alongside the workflow code.

No connector catalog. Every integration is just an activity that imports the vendor SDK and calls it: real type inference, real auth flows, real retry policies, no plugin layer either side. Activities run in the worker process, so dependency management is whatever your language community already uses (npm, pip, Maven, etc.).

Two native primitives: Schedules (cron-style triggering of workflows) and Signals (external events sent into a running workflow via gRPC). No native Kafka, Postgres CDC, SQS, MQTT or webhook trigger: you write a worker that consumes from those sources and starts workflows or signals existing ones.

Write another activity, deploy a new worker, or add a worker pool for a different queue. Custom auth, custom HTTP semantics and unusual integrations all live in activity code, with whatever helpers your team already wrote, no plugin or release cycle to wait on.

Pick an SDK, write a workflow function and one or more activities, run a worker process. The mental model takes some learning: the workflow / activity split, the determinism contract, signals and queries, and how to think about replay. The official Temporal University is solid; expect a few days for the first production-ready workflow.

Activity bodies are plain code in your SDK language: strip the activity decorator and you have a normal function that runs anywhere. What needs rewriting: workflow code itself (signals and queries, child workflows, search attributes, the determinism patterns) and any infrastructure tied to the Temporal server.

The Temporal UI shows a per-workflow event timeline (every state transition, signal and activity attempt) which is genuinely strong for debugging and replay. OpenTelemetry, Prometheus metrics and structured server logs are available in OSS. Advanced dashboards and managed monitoring are Temporal Cloud only.

The event history per workflow is itself an immutable audit trail of every decision and state change. Plus a separate audit log of API calls and admin actions, which is Temporal Cloud only on the higher tiers.

Self-hosted core ships mTLS and namespace-level auth. RBAC, SSO (SAML / OIDC), SCIM and fine-grained namespace permissions are Temporal Cloud only. Temporal Cloud is SOC 2 Type II, HIPAA and ISO 27001 compliant.

Namespaces isolate workflows, task queues and search-attribute schemas. Self-hosted supports multiple namespaces on one cluster. Temporal Cloud bills per-namespace storage and actions.

The Temporal Service is four roles (Frontend, History, Matching, internal Worker) plus a database (Postgres, MySQL or Cassandra) and optionally Elasticsearch for advanced visibility. Production self-hosting is non-trivial; many teams pick Temporal Cloud to avoid the operational lift.

Workers long-poll the Frontend service via gRPC; tasks dispatch through the Matching service, with state persisted by the History service to the database. The architecture is optimized for sequential durable workflows: in our benchmarks, Temporal is faster on long sequential workflows (per-step overhead lower thanks to the History service); Windmill is faster on parallel and fan-out workloads. Write amplification is real (roughly 7 events per activity).

MIT-licensed self-hosted core, the most permissive option. The core (server, SDKs, CLI, UI) is fully open-source. Enterprise-grade governance features (SSO, RBAC, SCIM, audit logs, namespace permissions, dedicated infra, multi-region) live exclusively in Temporal Cloud, not as a self-hostable Enterprise build.

Temporal Cloud is action-metered: Essentials $100/month (1M actions, 1GB active / 40GB retained storage), Business $500/month (2.5M actions, SAML SSO), Enterprise custom (10M+ actions, 24/7 support). Beyond base allocations, additional actions cost $50/M (declining to $25/M at 200M+). Storage charged separately at $0.042 per GBh active.