Temporal vs Inngest

Temporal rebuilds state by replaying history, so workflow code is a constraint the team must design for from the start. The Temporal Service records a complete, ordered event history for each workflow execution, and a worker that picks up a workflow after a crash or deploy reruns the workflow code against that history to restore its position. Replay only works if the code is deterministic: the same history must produce the same sequence of commands every time. Reading the wall clock, generating random values, calling external systems or reordering calls directly inside workflow code will break replay. Side effects belong in activities, and changes to workflow logic that in-flight executions depend on need versioning. Before each release, replay recorded histories from production against the new code. The Temporal workflows documentation sets out these rules.

Inngest starts from events and triggers, not from a long-lived process. A function is declared with a trigger (an event, a cron schedule or a webhook), can be governed by flow control (concurrency, throttling, debouncing, rate limiting and prioritization), and is split into steps that retry automatically. Each step is invoked over HTTP, so the application endpoint that serves the function must be reachable from the Inngest server, and the team needs to confirm how that path works in a private network or an air-gapped segment. The step is the unit of retry, so the team decides which operations become steps and makes each one idempotent, because a retried step will run its side effect again if the first attempt did not record completion. The Inngest README lists these building blocks.

Timeouts and versioning follow from where the code runs. On Temporal, timeouts are set per workflow and activity, and a worker that is still running old code keeps replaying old histories until its executions finish. On Inngest, each invocation is a short HTTP call, so the handler must return within the time limit of the hosting platform, and long waits are modeled as steps and sleeps rather than open connections. Redeploying changes the code that answers the next step invocation, so the team should confirm with the SDK documentation how in-flight runs are matched to renamed or reordered steps. A practical test is to start a multi-step run, redeploy mid-run, and confirm the run resumes correctly and that step retries behave as designed.

The running cost of a self-hosted Temporal Service comes mostly from infrastructure and engineering time. The Temporal Service runs Frontend, History, Matching and Worker services, and each needs a persistence store. The tested options are Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later. Cassandra deployments also need a separate visibility store, and Elasticsearch 7 or 8, OpenSearch 2 or later, or a SQL visibility store is the path for anything beyond a few workflow executions. Each of these is a separate cluster your team sizes, backs up and patches. Inngest's default footprint is far smaller: the CLI is a single binary with all services, using in-memory Redis and SQLite. That default does not scale beyond a single node, so any move to multiple nodes brings in external Redis and Postgres, which you must also operate.

Setup is largely one-time work: sizing the persistence and visibility stores, building Helm or Compose deployments, wiring mTLS, the Authorizer and OIDC for the Web UI, and proving a restore. Recurring costs are the monthly capacity of those stores, the staff time for upgrades (Temporal asks you to move one minor version at a time, with schema upgrades before server upgrades where the release notes require them), and the on-call effort for the cluster. Support is the other recurring line. Inngest's self-hosting docs say its support team does not guarantee direct support for self-hosted instances and point to enterprise options, so a self-hosted Inngest team should price in either that paid option or internal expertise. Temporal Cloud is the managed alternative, with pay-as-you-go pricing starting at 50 US dollars per million actions, plus storage charges, per Temporal's pricing page. That fee replaces infrastructure and upgrade work but adds a usage-based bill that grows with workflow volume.

When you ask for a written quote, ask the vendor or partner to itemize each component: the persistence and visibility stores, the number of Temporal or Inngest nodes, any Redis or Postgres required for scale, backup and restore testing, upgrade windows, and who answers support tickets. For Temporal Cloud, ask for the action volume, retained storage and active storage assumptions behind the estimate, and whether the SLA tier matches your requirement. For self-hosted Inngest, confirm the support level in writing, because the docs do not promise direct support. DeployOpen plans, implements and supports self-hosted platforms in your infrastructure under a fixed scope agreed in writing, and ongoing support and upgrades are available as retainers, so the quote should separate the one-time build from the recurring retainer.

On the Temporal side, the effort concentrates in the cluster and its security baseline before any workflow code is written. A self-hosted Temporal Service runs Frontend, History, Matching and Worker services plus persistence and visibility stores, so sizing the cluster, choosing a tested persistence engine (Cassandra, PostgreSQL or MySQL, with SQLite for development only) and deciding whether visibility runs on Elasticsearch or OpenSearch are early decisions that are hard to reverse. Confirm which persistence engine your platform team already operates and which versions it supports. Security is the other long pole: the default noopAuthorizer allows every API request, so mTLS for internode and frontend traffic, a ClaimMapper tied to your identity provider and an Authorizer must be configured and tested before any service connects. Payload encryption through a custom codec and codec server also needs a key management owner. Plan upgrades as one minor version at a time, with schema changes applied before server changes when the release notes call for them.

On the Inngest side, the first question is whether the default single-node SQLite persistence matches your availability and scaling expectations. The self-hosting documentation states that SQLite does not support scaling beyond a single node, and the Inngest CLI bundles services with an in-memory Redis by default. A production design that needs more than one node will move queue and state to external Redis and Postgres, which adds databases to back up, monitor and upgrade. Inngest's self-hosting documentation also says its support team does not guarantee direct support for self-hosted instances, so the team should decide who owns incidents and whether an enterprise support option is needed. Securing the endpoint that receives function invocations over HTTP is part of the scope, along with signing keys and network restrictions, and should be written into the work plan rather than assumed.

Before scoping either platform, confirm in your own environment: the persistence engines and versions your database team supports, whether your identity provider can issue the claims a Temporal ClaimMapper needs, who holds encryption keys for payload codecs, how many nodes you expect to run and their availability target, whether your network policy keeps services off the public internet, and who will answer for upgrades and incidents after go-live. Ask each vendor or partner to state these items in the written scope with named deliverables. A quote can then separate the one-time build (cluster deployment, security configuration, codec setup, migration from any existing scheduler) from recurring work such as upgrades, patch reviews and on-call support. Those answers usually drive the timeline more than the choice of SDK.