Durable Execution Without the $5B Price Tag: What Self-Hosted Inngest Actually Covers That a Queue Can't

In February 2026, Temporal raised $300 million at a $5 billion valuation, led by Andreessen Horowitz — double its $2.5 billion mark from the previous October. The pitch, per the Reuters report on the round, is infrastructure that keeps AI agents reliable in production. Read that valuation as a price signal: "the job survives a crash" is now premium infrastructure, worth five billion dollars as a category. Here is what that guarantee costs at the floor, before your workload grows into it:

The second row is the one this post is about. Inngest gives tenant background jobs the same crash-survival guarantee as ordinary HTTPS-invoked functions on the same fleet — without a managed queue vendor and without a license audit. But the honest version of that sentence has a second half, and it matters more than the first: self-hosting Inngest is community-supported, its server license is SSPL rather than permissive open source, and the cloud is unambiguously the default. This is a post about what self-hosted Inngest actually covers — and where the $5B alternative still earns its price.

What durable execution is (and what a queue can't do)​

A fire-and-forget queue promises delivery: the message will reach a worker. It does not promise completion. If the worker crashes halfway through a ten-step onboarding flow — user created, email sent, trial provisioned… then the container dies before the billing record — the queue redelivers the whole message and every step runs again. The email sends twice. The trial provisions twice. Your code grows idempotency guards on every step, which is to say you reimplement a workflow engine badly, spread across every handler.

Take the canonical tenant example: provisioning a paid sandbox means creating the record, charging the card, and issuing credentials. Crash between steps two and three and the naive retry charges twice while the customer holds zero credentials. The queue did its job — it delivered. Completion was never its contract.

Durable execution moves that bookkeeping into the platform. You write steps; the engine memoizes each step's result as it completes. On crash and retry, finished steps are skipped, not replayed:

export default inngest.createFunction(
  { id: "user-onboarding" },
  { event: "user/created" },
  async ({ event, step }) => {
    const user = await step.run("create-record", () =>
      db.users.insert(event.data),
    );
    await step.run("send-email", () => mail.sendWelcome(user.email));
    await step.run("provision-trial", () => billing.startTrial(user.id));
  },
);

If provision-trial throws or the machine dies mid-flow, the retry resumes at provision-trial — steps one and two are not re-executed. Retries, timeouts, concurrency limits, and crash recovery come with the engine instead of living in your codebase. Temporal invented this category's expectations; the question is what it costs to get them without Temporal's bill or operational weight.

The three options, priced and standardized​

Temporal is the most mature and the heaviest. A decade of production hardening, polyglot SDKs (Go, TypeScript, Python, Java), and roughly nine trillion lifetime executions on its cloud — the numbers cited in engineering evaluations this year run ~9.1T total with 1.86T from AI-native companies. Self-hosting means operating a real distributed system: a persistence layer plus history, matching, and frontend services. Teams that evaluate it consistently land in the same place: maximum maturity, maximum operational surface, with Temporal Cloud ($100/month floor) as the low-ops answer. You pay the premium or you become the operator. There is no third door.

Inngest is the DX-first answer. Event-driven functions behind a single HTTP endpoint; the cloud invokes your handler per step and memoizes by step label. The whole pitch is time-to-first-durable-workflow measured in minutes, and independent evaluations back that up — best developer experience in the category, excellent local dev server. The costs are specific and worth naming plainly. Every step is an HTTP invocation, so a ten-step workflow is ten invocations with their latency. Renaming a step breaks in-flight runs keyed on the old label. Retries consume execution quota on top of the run itself. Individual steps time out at two hours, which rules out very long-running operations as single steps. Trace retention is short on lower plans (about 24 hours on Hobby, 7 days on Pro). And self-hosting trails the cloud: a single Go binary plus Postgres, no support SLA, multi-node self-hosting not yet fully supported, and the server ships under SSPL — source-available, not a permissive open-source license. None of this disqualifies it. All of it belongs in the decision.

Restate is the license middle ground. MIT-licensed SDKs with a single self-contained Rust binary — durable log, workflow state machine, and state storage integrated, no external database to operate. The runtime sits under the Business Source License with what its authors describe as a minimal Amazon-style defense: fine to self-host, not OSI open source, and a license some organizations' policies still flag. If Inngest's SSPL bothers legal but Temporal's weight bothers ops, Restate is the compromise candidate — a smaller ecosystem in exchange for the smallest self-hosted footprint of the three. (Two more names for the shortlist: Hatchet, whose cloud has a genuinely free developer tier to 100,000 task runs a month, and DBOS Transact, MIT-licensed and library-only on top of Postgres you already run.)

The honest self-host burden ranking​

Rank by what you operate, not what you pay:

1. Restate — one binary, no mandatory external store. Closest to "run it next to the app and forget it."
2. Inngest — one Go binary plus Postgres you back up and scale yourself; single-node-friendly, multi-node on a best-effort basis, no SLA unless you pay for the cloud.
3. Temporal — a cluster of stateful services with its own persistence. Full-time-operator territory at any serious scale.

Notice what this ranking says: the cheapest bill (self-hosted Inngest on a box you own) is not the cheapest commitment. The Postgres behind Inngest needs backups, upgrades, and failover planning the moment tenant jobs matter — the same database discipline that sinks every "Postgres in a container" setup once the data matters. Concretely: scheduled base backups plus WAL archiving for point-in-time recovery, a restore procedure you have actually rehearsed, and a major-version upgrade plan. The engine's durability guarantee is only as strong as the database holding its step state. Self-hosting the engine saves the subscription; it does not save the on-call rotation. Go in with that priced, and the SQLite-backed dev server becomes the real story: local development with production-like step semantics and zero infrastructure, so the durability logic gets tested on every laptop before it ever meets your Postgres.

The parity claim is specific and testable: the same function code runs locally against SQLite-backed step state and in production against Postgres, with identical retry and memoization semantics. Step logic that passes locally behaves the same under crash in production, because the crash-recovery path — not just the happy path — executes in both places. For teams migrating off a hand-rolled queue setup, that makes adoption incremental: move one flow's steps behind the engine, keep the queue for the replay-safe remainder, and let the incident that would previously have double-charged a customer become the demo instead.

Which jobs need this, and the trigger for outgrowing it​

Not every background job deserves a workflow engine. Keep fire-and-forget queues and cron for idempotent, replay-safe work: sending a single notification, nightly cleanup scripts, cache warming. Reach for durable execution where a partial run is wrong, not just wasteful: payment and provisioning flows, multi-step onboarding, anything that coordinates with an external system that cannot un-receive a call, and increasingly agentic runs where step three depends on the model output of step two and restarting from zero burns real money.

Start with self-hosted Inngest when the shape fits: TypeScript or Python shop, HTTP-friendly steps under two hours, single-region tenants, and a team that already operates Postgres. The trigger for outgrowing it is equally concrete: steps that exceed the timeout ceiling, multi-node HA requirements the community self-host path cannot carry, polyglot workers beyond the supported SDKs, or audit/compliance needs that want Temporal's decade-long paper trail. "Might need it someday" is not the trigger; a named workload that violates one of those four constraints is.

Temporal's $5 billion says durable execution won. The good news buried in that number is that winning created a middle: crash-surviving step functions your tenants can call like ordinary functions, running on infrastructure you own, backed by SQLite on a laptop and Postgres in production. Own the engine, budget the ops, and keep the receipt for the day a workload outgrows it.

Running tenant background jobs that must survive a crash? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.