Temporal vs Hatchet

Hatchet's README presents its durable tasks feature as a drop-in replacement for Temporal or DBOS workflows, but that claim covers durable tasks, not every pattern a Temporal team writes. Temporal workflows are written as code in general-purpose languages, and the Temporal Service keeps a complete ordered event history so a workflow can be replayed and resumed after a failure. That replay model is what imposes determinism rules on workflow code: the same code path must run again on replay, so non-deterministic calls such as reading the clock or random values must go through the SDK. Hatchet's durable tasks and DAG workflows use a different model, with tasks, dependencies, durable sleep and event waits, so a migration is a change of execution model, not a change of SDK.

Before accepting the claim for your estate, run a short test on your own workflows. Check whether any workflow depends on Temporal's replay semantics, such as relying on a specific ordering of activities after a worker restart. Check how you version running workflows when code changes, since Temporal's versioning and history rules are part of how long-running executions survive deployments, and confirm Hatchet's equivalent for in-flight runs. Then test signal-style patterns, where external messages change a running workflow, and confirm how Hatchet's event waits behave when the event arrives before or after the wait begins. Ask Hatchet to show these behaviors in a worked example with your own failure cases, and treat any gap as a migration cost to plan for rather than a detail to resolve later.

The first decision on identity is whether anything in front of a self-hosted Temporal Service is actually enforcing access. If no Authorizer is configured, Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. A production deployment therefore needs an explicit authorization setup before the cluster takes traffic. Temporal provides the pieces for this: mTLS with separate settings for internode and frontend traffic, a ClaimMapper that maps JWT or certificate claims to namespace roles, an Authorizer plugin, OIDC single sign-on for the Web UI, and payload encryption through custom codecs and a codec server. Your team will assemble these from configuration and its own identity provider, so the work is real engineering effort and should appear in the implementation scope.

Hatchet takes a different starting point. Its README says a single instance is multi-tenant by default, with users and roles built in, and it attributes SSO to Hatchet Cloud rather than to the self-hosted control plane. That makes the self-hosted SSO and tenant isolation questions the ones to settle first. Confirm with Hatchet, against the self-hosting documentation, whether SSO is available for a self-hosted control plane and how it is configured, how tenants are separated in the database and API, and whether the API server, gRPC engine, dashboard and RabbitMQ can be isolated per tenant. Ask for the answers in writing and test them with two tenants before you rely on them.

Network exposure is the same question for both platforms, and the Temporal deployment documentation is explicit: Temporal services should run on hosts not reachable from the public internet, with network access restricted to trusted internal networks. Apply the same rule to the Hatchet API server, gRPC engine, dashboard and PostgreSQL database, and to any RabbitMQ management interface. Workers need network paths to the control plane, so plan which subnets, load balancers and firewall rules they will use, and whether Temporal's frontend or Hatchet's gRPC endpoint will ever be reachable beyond your private network. Treat that boundary as a design requirement rather than a later hardening task.

Temporal projects usually run long on decisions made before any workflow code is written. The deployment method (Docker Compose, Go binaries, Helm charts on Kubernetes, or a custom Go build) sets how the Frontend, History, Matching and Worker services are operated, and the Helm chart version must match the server image, since charts below 0.73.1 do not work with server images 1.30 and later. Persistence is the next long lead item: Cassandra, PostgreSQL or MySQL, each on a tested version range, with a separate visibility store that Elasticsearch or OpenSearch should back once executions grow. Security is the third. A Temporal Service with no Authorizer runs the default noopAuthorizer, which allows every API request, so the client team must decide on mTLS, the ClaimMapper, OIDC for the Web UI and payload codecs before go-live. The longest delay is usually workflow determinism: engineers must learn which code changes break replay, and versioning discipline must be agreed before the first production change. The client team should supply developers who will own the workflow code, a network owner who keeps services off the public internet, and a platform owner for the upgrade path, which moves one minor version at a time.

Hatchet projects run long on a smaller control plane but on more tenant and queue design. The control plane is an API server, a gRPC engine, PostgreSQL, an optional RabbitMQ queue and a dashboard, and the choice between Hatchet Lite, Docker Compose and Helm on Kubernetes should follow the throughput the client expects, not the quickest demo. Worker deployment is where most time goes: each worker type needs its own slot settings, and rate limits, priority and concurrency-based fair scheduling must be tuned against real load before they behave as intended. Tenant setup is the other common delay. A single instance is multi-tenant by default with users and roles, so the client must define which teams, environments and roles map to which workflows, and confirm that this model meets its separation requirements. Clients should also confirm SSO arrangements, since the README places SSO on Hatchet Cloud, and confirm whether their self-hosted setup needs it. The client team needs to supply PostgreSQL and queue operators, workflow owners who will tune concurrency, and a decision on OpenTelemetry and Prometheus integration.

DeployOpen plans and implements self-hosted platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Work is typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so the points above should be settled in the statement of work. Ask any implementation partner, DeployOpen included, to state which of the deployment, persistence, security, determinism and tenant decisions are in scope, which the client must make, and which need a retainer for ongoing upgrades and testing.