Inngest

Workflow orchestration for developers who’ve lost a job to a crashed process. Honestly reviewed — no marketing copy, just what you actually get.

TL;DR

• What it is: A workflow orchestration platform that wraps your existing code in durable, retry-safe “steps” — replacing the need to manage queues, state machines, and dead-letter queues manually [4].
• Who it’s for: Backend developers and engineering teams building AI pipelines, background jobs, or multi-step workflows on serverless or traditional infrastructure. Not a no-code tool [3][4].
• Cost vs. alternatives: Free tier for personal use; paid plans from approximately $50/mo for teams; enterprise custom pricing. Self-hosted is possible with a single binary or Docker container [1][3].
• Key strength: The developer experience is unusually clean. You write normal functions, wrap steps in step.run(), and Inngest handles retries, state persistence, flow control, and observability automatically [5].
• Key weakness: This is a developer-only tool. Non-technical founders cannot use this without an engineer. The license is not a standard open-source license — self-hosting is supported but the terms are not MIT or Apache [1][README].

---

What is Inngest

Inngest is a workflow orchestration engine. The pitch is: you already write functions; Inngest makes them durable. Instead of wiring up a job queue, a retry system, a state database, and a monitoring dashboard, you wrap your existing TypeScript/Python/Go code in Inngest’s step.run() primitives, and all of that infrastructure is handled for you.

The problem it solves is real. Any developer who has built AI pipelines or multi-step background jobs has hit the same failure mode: step 1 succeeds (say, downloading a video), step 2 crashes (transcription OOM), and you lose the work from step 1. Without careful memoization, you re-run everything. With Inngest, completed steps are persisted automatically — a crash at step 3 picks up from step 3, not from the beginning [4][5].

As of this review, the GitHub repository sits at 5,062 stars. The company behind it is VC-backed and targets production engineering teams. SDKs exist for TypeScript/JavaScript, Python, Go, and Kotlin/Java [README]. The platform runs against the Inngest cloud (their hosted service) or a self-hosted server that ships as a single binary [1].

The architecture is more complex than most tools in this category: Event API → event stream → Runner → Queue → Executor → State Store + Database + Dashboard UI [1]. All of that is bundled into the single CLI binary for self-hosting, which hides the complexity, but the complexity is real if something breaks.

---

Why people choose it

The consistent reason engineers reach for Inngest is the failure-recovery problem in AI and background job workflows. The Directus integration tutorial [5] puts it plainly: AI operations are long-running, resource-intensive, and composed of multiple steps — data preparation, model inference, result processing — each of which can fail independently. Standard job queues don’t give you per-step retry semantics. Inngest does.

The practical contrast with rolling your own:

Without Inngest: you write a script that runs steps 1–4 sequentially. It crashes at step 3. You either restart from step 1 (wasting step 1 and step 2 compute) or you write your own checkpointing logic (which is the hard part). Add retries, concurrency limits, observability, and this becomes its own engineering project.

With Inngest: each step.run() call is a transaction. Completed steps don’t rerun. Failed steps retry automatically. The dashboard shows you exactly which step failed, what the input was, and what the error was — without grepping logs across systems [5].

JoelClaw’s self-hosting writeup [4] describes running 14 functions across two pipelines: a video ingest pipeline (5 steps across 3 tools) and autonomous coding loops. The point about reboots is underrated: “The machine reboots, the job picks up where it left off.” For long-running AI workflows that take 20–40 minutes, this is the difference between an agent you can trust and one you babysit.

Versus Temporal: Temporal is the enterprise incumbent in durable workflow orchestration. It’s more powerful for extremely complex, long-running sagas but requires running and operating separate worker infrastructure. Inngest’s angle is that your functions live in your existing app — you deploy your app, Inngest calls it via HTTPS [1][3]. No separate worker fleet to manage.

Versus Trigger.dev: The closest direct competitor in the TypeScript-first space. Both solve the same problem. Trigger.dev is more open-source-committed (MIT license). Inngest has a more mature dashboard and observability story, and supports more languages. The choice usually comes down to language ecosystem and which dashboard you prefer.

Versus AWS Step Functions: Step Functions requires you to define workflows in JSON/YAML state machine syntax, away from your code. Inngest keeps workflow logic in code, colocated with business logic. Engineers consistently prefer the Inngest DX for this reason [5].

The SoundCloud CTO testimonial on the homepage captures the appeal: “Our context switching dropped significantly, because the code is just business logic. If you read the code, you know the steps that will execute without having to manage any infrastructure.”

---

Features

Based on the README, documentation, and third-party articles:

Core execution model:

• step.run() — atomic, memoized step. Retries automatically on failure. Runs exactly once on success [5][README]
• step.sleep() — pause execution for days or weeks without holding a thread [README]
• step.waitForEvent() — pause until a matching external event arrives, with optional timeout [1]
• step.ai.infer() — dedicated step for AI model inference with automatic retry and tracing [homepage]
• State automatically persisted between steps — no external state database needed [5]

Triggers:

• Event-based: functions fire when matching events arrive via SDK or HTTP
• Cron/schedule: time-based triggers built in
• Webhook events from external services [3][README]

Flow control:

• Concurrency limits with per-key scoping (e.g., limit 10 concurrent runs per userId) [README]
• Rate limiting and throttling
• Debouncing (collapse many events into one execution)
• Batching
• Priority queues [homepage][1]

Observability:

• Full step-by-step traces in the dashboard, including prompt/response pairs for AI steps [homepage]
• Metrics, logs, error tracking
• Replay: re-run failed function runs in bulk after a bug fix [homepage]
• Bulk cancellation [homepage]

Self-hosting:

• Single CLI binary includes all services (Event API, Runner, Queue, Executor, Dashboard) [1]
• Docker image available [4]
• Default config: SQLite for persistence, in-memory Redis for queue/state
• External PostgreSQL and Redis configurable for production [1]
• Dashboard served at localhost:8288

Security (enterprise-gated):

• SOC 2 compliant
• E2E encryption middleware
• SSO and SAML — enterprise tier
• HIPAA BAA available
• 100K+ executions per second capacity [homepage]

---

Pricing: SaaS vs self-hosted math

Pricing details from the public sources are limited. TechShark [3] cites “Freemium, $50/mo” for team plans, with a free developer tier and enterprise custom pricing.

Inngest Cloud:

• Free tier: Exists, described as “generous” on the homepage — suitable for personal projects and experimentation
• Team plans: Approximately $50/mo (exact tiers and run limits not published in the sources reviewed — check the current pricing page)
• Enterprise: Custom pricing, includes SSO, SAML, HIPAA BAA, dedicated support

Self-hosted:

• Software: available as open binary; license is not MIT or Apache — review the terms at the GitHub repo before commercial use
• Infrastructure: one Docker container on a VPS handles a local or small-team deployment [4]
• A $10–20/mo VPS covers personal or small-team self-hosting
• External Redis and PostgreSQL recommended for production (adds cost and ops overhead)

Competitors for comparison:

• Temporal Cloud: usage-based, typically $25–200+/mo depending on execution volume; self-hosting requires running multiple services
• Trigger.dev Cloud: free tier, $20–100+/mo for team plans; MIT-licensed for self-hosting
• AWS Step Functions: $0.025 per 1,000 state transitions; costs scale with complexity

For a small team running moderate AI pipelines, the Inngest free tier is usable and the $50/mo team plan is competitive with what you’d spend building and operating equivalent queue infrastructure yourself. Self-hosting trades the monthly bill for VPS cost plus ops time.

---

Deployment reality check

Self-hosting Inngest is genuinely straightforward for anyone comfortable with Docker. JoelClaw’s guide [4] documents the current reality:

docker run -d --name inngest \
  -p 8288:8288 \
  -v inngest-data:/var/lib/inngest \
  -e INNGEST_SIGNING_KEY="$INNGEST_SIGNING_KEY" \
  -e INNGEST_EVENT_KEY="$INNGEST_EVENT_KEY" \
  --restart unless-stopped \
  inngest/inngest:latest \
  inngest start --host 0.0.0.0

One container. Dashboard at localhost:8288. For a developer building personal tools or internal pipelines, this is about 30 minutes from zero to working.

Important caveat as of February 2026: signing keys are now mandatory [4]. Without INNGEST_SIGNING_KEY and INNGEST_EVENT_KEY, the container crash-loops with Error: signing-key is required. The official docs [1] cover this, but older tutorials and StackOverflow answers predate this requirement.

What the default config gives you:

• SQLite for persistence (fine for dev, workable for light production)
• In-memory Redis (loses state on restart — snapshots are saved to SQLite periodically)
• Dashboard + API + Event API on one port (8288)
• Connect gateway on port 8289

What you need for production self-hosting:

• External Redis instance (Upstash or self-hosted) for reliable queue/state
• External PostgreSQL for event history and function run records
• Reverse proxy (Caddy or nginx) for TLS
• Your app deployed somewhere Inngest can reach via HTTPS — Inngest calls your functions by making HTTP requests to your serve endpoint [2]

That last point is worth emphasizing: Inngest doesn’t run your code. It runs the Inngest server (event routing, scheduling, orchestration) and calls your application’s functions via HTTP. Your app needs to be deployed separately and exposed via a URL that the Inngest server can reach [2]. This is the architecture — it means your business logic stays in your existing codebase and deployment pipeline, but it also means self-hosting Inngest is only half the picture.

For a developer running everything locally: npx inngest-cli@latest dev spins up the dev server with a dashboard that has full production parity — same traces, same step visualization, same flow control debugging [README]. This is genuinely good for local development.

Realistic time estimates:

• Local dev setup: 15–30 minutes
• Self-hosted Docker on VPS with SQLite: 1–2 hours
• Production-grade self-hosted (external Redis + Postgres + TLS): half a day
• Non-technical user doing any of the above: not realistic without engineering help

---

Pros and cons

Pros

• Step-level durability with no infrastructure. step.run() gives you memoized, retry-safe execution. This takes weeks to build correctly on your own; Inngest gives it to you in one API call [5][4].
• Local dev experience is excellent. The dev server runs with one CLI command and gives full production parity — real traces, step visualization, event replay — without any cloud dependency [README][homepage].
• Multi-language SDK support. TypeScript, Python, Go, and Kotlin/Java. Most competitors in this space are TypeScript-only [README].
• AI workflow-native. step.ai.infer() adds tracing for prompt/response pairs automatically. Built for the multi-step AI pipeline pattern [homepage].
• Observability without extra instrumentation. Traces and metrics are automatic, not something you bolt on later [3][5].
• Self-hosting is genuinely one container for dev/small-team use [4].
• Flow control is first-class: concurrency keys, throttling, debouncing, batching — things you’d otherwise implement yourself or pay for via a queue provider [1][README].
• SOC 2, HIPAA BAA, E2E encryption available for enterprise deployments [homepage].

Cons

• Not for non-technical users. This requires writing code. There is no visual workflow builder, no drag-and-drop, no template library for non-developers. The entire value proposition is “write better code” — which requires being able to write code [4][5].
• License is not standard open source. The GitHub license field shows “NOASSERTION” in the merged profile. The source is available but the terms aren’t MIT or Apache — verify before building commercial products on a self-hosted instance.
• Your app must be publicly reachable by the Inngest server. This is an architectural constraint, not a bug, but it means pure local-only or air-gapped deployments require extra work. Self-hosting both pieces doesn’t change this requirement [2][1].
• In-memory Redis by default means state loss on container restart without the SQLite snapshot — a footgun for anyone following a quick-start and skipping this detail [1].
• Small GitHub footprint for a production tool: 5,062 stars is respectable but significantly behind Temporal (~12K) or n8n (~100K+). Community size matters for finding help and integrations.
• Pricing is opaque. The public sources don’t show a full pricing page with tier limits. You have to visit the site to see current rates — this review can’t give you the definitive numbers [3].
• The “self-hosted” story has a catch. Inngest handles orchestration. Your application code runs separately and must be deployed to an endpoint Inngest can call. This is two infrastructure pieces, not one [2].

---

Who should use this / who shouldn’t

Use Inngest if:

• You’re a developer or engineering team building AI pipelines with multi-step inference, document processing, or data enrichment — anything where step-level retry matters.
• You’re running background jobs on serverless (Vercel, Netlify, Lambda) and have hit the timeout/reliability wall that serverless functions impose.
• You want durable execution semantics without adopting Temporal’s operational complexity.
• You want local dev tooling that mirrors production exactly.
• Your team writes TypeScript, Python, or Go and wants SDK-native workflow definitions rather than YAML/JSON state machine configs.

Skip it (use Temporal instead) if:

• You’re building enterprise-grade, long-running sagas (days to weeks) with complex compensation logic.
• Your org already runs Temporal and has the operational expertise.
• You need the largest possible community and ecosystem.

Skip it (use Trigger.dev instead) if:

• MIT license is a hard requirement for your use case.
• You’re TypeScript-only and want tighter open-source commitments.

Skip it (use n8n or Activepieces instead) if:

• You’re a non-technical founder or marketing team. Those tools have visual builders. Inngest does not.
• You’re connecting SaaS apps (Gmail → Slack → Notion) without custom code.

Skip it entirely if:

• You need something you can hand to a non-developer to configure and run.
• Your “background jobs” are simple enough to handle with a cron tab and a retry loop — Inngest’s power is overkill for simple scheduled tasks.

---

Alternatives worth considering

• Temporal — the enterprise standard for durable workflows. More powerful for complex long-running sagas, heavier operational footprint, larger community. Strong open-source commitment (MIT for the core). [3]
• Trigger.dev — closest direct competitor to Inngest. TypeScript-first, MIT-licensed, similar step model. Less mature multi-language support. Growing fast.
• AWS Step Functions — fully managed, no self-hosting option. Workflow logic lives in JSON state machines, not your codebase. Pricing is per state transition and can surprise you at volume. [3]
• Prefect — Python-first workflow orchestration. Strong for data engineering and ML pipelines. Less suited for web application background jobs. [3]
• n8n — open-source workflow automation with a visual builder. Completely different audience (no-code/low-code) but overlaps on “event-driven automation.” [3]
• BullMQ + Redis (DIY) — if your needs are simple and TypeScript-only, a job queue is cheaper and simpler than a full orchestration platform. The point where this breaks down is step-level retry semantics and long-running jobs.

---

Bottom line

Inngest solves a real and expensive problem: background jobs that crash partway through, AI pipelines that have to restart from scratch, and the operational burden of building retry/state infrastructure that every team reinvents. The step model is clean, the local dev tooling is genuinely good, and the observability is automatic rather than bolted on. For a developer building AI workflows in 2025, it’s one of the more honest “just wrap your code” pitches in the space.

The caveats are real: this is not a self-hosted tool for non-technical founders, the license deserves scrutiny before commercial deployment, and the production self-hosting setup (external Redis, external Postgres, HTTPS-accessible app endpoint) requires more operational knowledge than the quick-start implies. But if you’ve ever lost an 8-step AI pipeline because your machine went to sleep on step 6, Inngest is worth a serious look before you build that checkpointing system yourself.

---

Sources

1. Inngest Documentation — Self-hosting (official docs). https://www.inngest.com/docs/self-hosting
2. Inngest Documentation — Syncing an Inngest App (official docs). https://www.inngest.com/docs/apps/cloud
3. TechShark — “Inngest Reviews: Key Features, Pricing, & Alternatives” (updated 01/17/2026). https://techshark.io/tools/inngest/
4. JoelClaw — “Self-Hosting Inngest: A Background Task Manager for AI Agents”. https://joelclaw.com/self-hosting-inngest-background-tasks
5. Directus Docs — “Invincible AI Content Workflows with Inngest and Directus”. https://directus.io/docs/tutorials/workflows/invincible-ai-content-workflows-with-inngest-and-directus

Primary sources:

• GitHub repository and README: https://github.com/inngest/inngest (5,062 stars)
• Official website: https://www.inngest.com
• Documentation: https://www.inngest.com/docs