Temporal

Last reviewed Aug 26, 2026 · 736 words

Temporal is not an automation tool in the n8n sense, and most of the Hard rating comes from people discovering that too late. There are no nodes, no drag-and-drop, no prebuilt integrations. It is a runtime that makes a function in Go, Python, TypeScript, Java, .NET, PHP or Ruby survive anything: the process dies mid-run, the machine reboots, you deploy a new version, and the workflow resumes at the exact line it was on with every variable intact, even if it had been sleeping for 30 days. If you write code and have ever hand-rolled a retry table in Postgres to make a long process reliable, Temporal replaces that table and the cron job that polls it. If you want to wire a mailbox to a spreadsheet, close this page and open n8n.

Durable execution in one paragraph

A workflow function calls activities, which are the actual side effects: HTTP calls, database writes, emails. Temporal records every activity result in an event history. When a worker crashes and another picks the workflow up, it replays that history to rebuild state and continues from the first activity with no recorded result. Retries, timeouts, backoff and heartbeats are declared per activity, not hand-written. The rule this imposes is that workflow code must be deterministic: no wall-clock reads, no random numbers, no direct I/O inside the workflow function, only inside activities. Every Temporal bug I chased in my first month was a determinism violation.

What the server actually is

Four services (frontend, history, matching, worker) that can run as one process, a persistence store, and optionally Elasticsearch for advanced workflow search. The frontend speaks gRPC on port 7233; the web UI is a separate container on port 8080. Postgres is the sane store for self-hosting, and because visibility data can live in Postgres too, Elasticsearch is optional at homelab scale.

temporal server start-dev --ui-port 8080

That CLI command runs a complete server with an embedded store on your laptop, and it is how you should spend the first week. For real deployment, the temporalio/docker-compose repository has compose files for Postgres, and the temporalio/auto-setup image creates the schema on first boot. The 2 GB RAM floor covers server, UI and Postgres at idle; workers are your own processes and scale separately from the server.

The honest operational cost

Namespaces, retention (event history is kept for a configured number of days, then deleted), schema migrations on server upgrades, and the fact that server, SDK and worker versions have compatibility windows. Upgrades are documented and sequential; skipping server versions is not supported. Monitoring matters because a stuck workflow is silent by design: it is waiting, exactly as told. Export the server's Prometheus metrics and alert on schedule-to-start latency. None of this is hard for someone already running Postgres; it is a lot for someone whose automation lives in one container. Temporal Cloud exists for people who want the SDK without the server, and I would not judge anyone for taking it.

Where it fits in a self-hosted stack

The clean home-scale cases: a media pipeline that downloads, transcodes, tags and notifies over hours with each step retried independently; a provisioning flow that creates a user in 5 systems and rolls back on failure; a monthly reminder process that sleeps for weeks between steps. If your process runs under a minute and is idempotent, a script with a retry loop is fine. The Step Functions alternatives page compares the other engines in this class.

What I'd do

Start with temporal server start-dev and the Python or TypeScript SDK sample for a week. Move to the compose deployment on Postgres only once a workflow you actually depend on exists. Skip Elasticsearch, set retention to 7 days, put the UI behind the reverse proxy with authentication, scrape the metrics. Keep n8n for everything that is glue. Temporal earns its place for the 2 or 3 processes where losing state costs real money or real embarrassment; for those, nothing else self-hosted comes close.