Inngest: event-driven workflows for TypeScript and Python with durable execution

What is Inngest?

Inngest is a platform for event-driven workflows with durable execution, founded 2021 by Tony Holdstock-Brown and Dan Farrelly in San Francisco. Market position is concrete: Inngest targets developer teams working in TypeScript or Python who want to keep workflows as code directly in the application – without a separate workflow-server setup like Temporal or Airflow.

The concept works in three layers. First layer: SDK inside the application (TypeScript, Python). Functions are marked as "Inngest Functions" with decorator/wrapper, their steps structured with step.run, step.sleep, step.waitForEvent. Second layer: Inngest Cloud or self-host (the Inngest server is Apache 2.0 under open-source license). The server triggers functions via events, manages state, and guarantees retry. Third layer: the event model. Instead of directly starting workflows, the application sends events ("user.signed_up", "payment.received", "invoice.generated"); the Inngest server decides which functions react.

As of May 2026 SDKs are available in TypeScript, Python, Go, Kotlin, plus experimentally in Java and Rust. Functionality is most mature in TypeScript – many examples and patterns come from the Next.js and Node.js ecosystem.

Commercially Inngest has two paths. First: Inngest Cloud – Free with 50,000 function runs/month, Hobby with USD 0/month for smaller setups, Pro from USD 50/month for 250,000 runs plus concurrency features, Enterprise on request. Second: self-hosted – the Inngest server has been Apache 2.0 on GitHub since 2024. Self-host is a valid option for teams that must keep data in EU/CH.

The cloud runs primarily on US-AWS regions, a dedicated EU region is not provided by default. Anyone needing Inngest under EU law switches to self-host.

Why it matters

Inngest solves a problem specifically relevant for TypeScript engineering teams: durable execution with sleep and wait-for-event directly inside the application, without a separate workflow-server cluster. Anyone building a Next.js or Express app and modelling workflows like "user signs up -> welcome mail -> 24h later onboarding tip -> 7 days later re-engagement" can express that in Inngest in 30 lines of TypeScript.

The comparison with Temporal is instructive. Temporal is more powerful and linguistically more diverse (7 SDKs), but the setup is more complex (multiple server components, own worker processes). Inngest is optimised for minimal setup: workflows live in the existing application, the server comes as cloud or as a single Docker container. For teams in the "mid-range" between simple workflows (n8n) and mission-critical distributed (Temporal), Inngest is the right choice.

For a Swiss fiduciary, realistic levers are narrower than for n8n but concrete. First – onboarding workflows for SaaS products. When a fiduciary platform offers an own SaaS solution (self-service bookkeeping, client portal), Inngest functions are the idiomatic choice for user-lifecycle logic. Welcome mail after signup, trial expiry after 14 days, re-engagement after inactivity.

Second – background jobs in a web app. Anyone building an Express or Next.js app often has background jobs (generate PDF, send mail, external API calls with retry). In Inngest these jobs are written as regular functions with sleep and retry logic – no separate BullMQ or Sidekiq setup needed.

Third – webhook processing. Stripe, HubSpot, GitHub, and other SaaS vendors send webhooks. Anyone wanting to process them reliably (retry on failure, deduplication, idempotent processing) can use Inngest as a webhook receiver. The Inngest server takes over persistence, the app takes over business logic.

Downsides: cloud hosting in the US, self-host still younger than n8n or Activepieces, smaller community. Anyone needing self-host should first check whether the setup effort matches the functional gain.

How it works

An Inngest system has two parts: the SDK inside the application and the Inngest server (cloud or self-host). In code you define functions that react to events. A function has a name, an event trigger, and an async function with the logic. The logic is structured in "steps" – step.run, step.sleep, step.waitForEvent.

A typical TypeScript example: `inngest.createFunction({ id: "onboard-user" }, { event: "user/signed_up" }, async ({ event, step }) => { await step.run("send-welcome", () => sendWelcomeMail(event.data.email)); await step.sleep("wait-24h", "24h"); await step.run("send-tip", () => sendOnboardingTip(event.data.email)); });`. On a "user/signed_up" event, the Inngest server starts the function. Step 1 (welcome mail) is executed. Then the server waits 24 hours, persists state, and invokes the function again – this time with the step 1 result from history so step 2 (tip mail) executes.

Steps are the durable execution model. If the server crashes between step 1 and step 2, after restart it replays the function – step 1 is delivered from history (not re-executed), step 2 is started fresh. Idempotency is guaranteed by step IDs provided steps are written idempotently.

Events are the central trigger source. Instead of directly invoking functions, the app sends events: `await inngest.send({ name: "user/signed_up", data: { email: "..." } })`. The server decides based on registered functions which functions process the event. Several functions can process the same event, one function can process several events.

The architecture supports three trigger types: events (async, with fan-out), cron schedules (time-based), and scheduled functions (delayed). Plus the step.waitForEvent function that waits in-workflow for an external event – for approval flows or multi-step processes.

The SDK communicates with the server via HTTP. With self-host, the server is a Docker container that must be reachable on the application's webhook URL. With cloud hosting, all of that runs in the background. Latency between event and function start is typically 100-500 milliseconds.

Concurrency control ("concurrency limits") is a particular strength: per function or per event key, you can define how many instances may run in parallel. That avoids backpressure on external APIs – e.g. "max 5 parallel Stripe calls per second".

Integrate Inngest in 5 steps

1. 01Create an Inngest account (Cloud Free for start) or deploy the self-host server as a Docker container (Apache 2.0 on GitHub).
2. 02Install the SDK in the app (npm install inngest or pip install inngest), client init in a config file.
3. 03Expose the webhook endpoint: Next.js api/inngest or an Express route, the Inngest handler registers all functions.
4. 04Write the first function: createFunction with event trigger, async logic with step.run and step.sleep, test locally with npx inngest-cli dev.
5. 05Activate monitoring: Inngest Cloud dashboard for function runs, Slack/mail alerts on failure rate > 1%, set concurrency limits for external API calls.

When to use Inngest

Inngest is the right pick when (a) the team writes TypeScript or Python, (b) workflows should be kept as code directly inside an existing application, (c) durable execution with sleep and wait-for-event is required, and (d) setup effort should stay minimal.

Concrete cases: user-lifecycle workflows in SaaS products (onboarding, trial expiry, re-engagement, churn winback), background jobs in web apps with retry logic (PDF generation, mail dispatch, external API calls), reliable webhook processing (Stripe, HubSpot, GitHub), multi-step processes with user approval (order approval, client onboarding with AML check), time-based workflows with sleep (e.g. "send reminder in 7 days").

For engineering teams in mid-sized SMEs or fiduciary platforms with TypeScript backend stacks (Next.js, Express, Hono), Inngest is the idiomatic choice. The learning curve is low (a function with step.run written in 30 minutes), the cloud variant covers the first 50k runs free.

For self-host in EU/CH, Inngest has been a valid option since 2024. The server runs as a single Docker container, setup takes 30 minutes. Compared to Temporal (several server components plus database), Inngest is markedly easier to operate.

For standard RAG and agent workflows, Inngest with custom LangChain wiring in TypeScript or Python fits well. A RAG pipeline can be implemented as an Inngest function with step.run steps – embedding, vector-store search, LLM call.

When not to use

Inngest is the wrong choice for no-code teams. A cloud UI for function monitoring exists, but no drag-and-drop editor. Marketing or sales teams without engineering resource cannot run Inngest themselves – n8n, Make, Activepieces, or Zapier are the right choice.

Unsuited for pure drag-and-drop SaaS wirings without code. Anyone building "Slack message on new HubSpot deal" has 5 minutes of setup in Zapier or Make, in Inngest it needs a code stack (Node.js or Python) and a server deployment.

Does not fit when the use case is clearly data engineering (ELT, data warehouse, ML training). Airflow or Dagster are more productive there – Inngest is optimised for transactional workflows in applications, not data pipelines.

For very broad connector requirements (connect hundreds of SaaS apps), Inngest is not the right tool. There are no predefined connectors – every integration runs as a regular code call inside the app. n8n with 600+ nodes or Make with 1,500+ apps are faster there.

For IoT/IIoT applications, Inngest is unsuited – no MQTT, Modbus, or OPC-UA support. Node-RED is the right choice there.

For very high volume with real-time constraints (millions of events/second), Inngest is not optimised. The platform comfortably sits in the thousands-of-events-per-second range; for more, Kafka, Apache Flink, or dedicated streaming platforms are needed.

Trade-offs

FAQ

Related topics

Sources

1. Inngest documentation – functions, steps, events · 2026-05
2. Inngest pricing page · 2026-05
3. Inngest on GitHub – Apache 2.0 server and SDKs · 2026-05
4. Inngest durable execution and step model · 2026-04