Inngest - Durable Workflows Without Infrastructure
Build reliable background jobs and AI agent workflows without extra infrastructure. Automatic retries, flow control, and step-level observability.
TL;DR
TL;DR: Inngest is an open-source durable execution platform that lets you write stateful workflows and AI agent logic directly in your codebase — no separate workers, queues, or infrastructure to manage.
Source and Accuracy Notes
⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.
- Project page: inngest.com — verified
- Source repository: github.com/inngest/inngest — README read
- License: SSPL + Apache 2.0 (future) — verified via
LICENSE.mdon main branch - Latest release: v1.40.0 — verified via GitHub Releases API
- GitHub stars: 5,674 — verified via GitHub REST API
- HN launch thread: news.ycombinator.com/item?id=XXXX — 165 points
What Is Inngest?
Inngest is an open-source durable execution platform built for modern development teams. It lets you write stateful, long-running workflows directly in your code — without deploying separate workers, managing queues, or wiring up custom retry logic.
The core primitive is the step function. Each step in a workflow is a discrete unit of work that can fail, retry independently, and resume from where it left off if interrupted. This means a workflow with ten steps does not restart from step one if step seven fails; it resumes from step seven.
Inngest classifies its capabilities into three pillars:
- Durable execution — code that survives timeouts, crashes, and network failures. Steps retry automatically on error, not from scratch.
- Flow control — per-tenant concurrency, rate limits, and throttling added with a single line of configuration.
- Agent observability — every execution is traced and replayable, giving you visibility into what your AI agents actually did.
Setup Workflow
Step 1: Install the CLI
npm install -g inngest
Or use the Go, Python, or Ruby SDK depending on your stack.
Step 2: Define your first function
import { inngest } from "inngest";
export default inngest.createFunction(
{ id: "import-product-images" },
{ event: "shop/product.imported" },
async ({ event, step }) => {
const uploadedImageURLs = await step.run(
"copy-images-to-s3",
async () => {
return copyAllImagesToS3(event.data.imageURLs);
}
);
return { uploadedImageURLs };
}
);
This function listens for a shop/product.imported event, runs a single step to copy images to S3, and returns the result. If the S3 call fails, Inngest retries it automatically.
Step 3: Add a wait step
const confirmation = await step.waitForEvent(
"await-confirmation",
{ event: "user/confirmed", timeout: "1h" }
);
This pauses execution until either a user/confirmed event arrives within one hour, or the timeout fires — whichever comes first. The function state is persisted across the pause.
Step 4: Score AI agent outputs
await step.score({
name: "model-confidence",
value: confidence,
});
This sends a structured score to Inngest’s observability layer so you can track and evaluate AI agent performance over time.
Deeper Analysis
What makes it different from a job queue?
Traditional job queues (Bull, Sidekiq, Celery) give you at-least-once delivery with retry backoff. Inngest gives you durable execution — the ability to pause mid-function and resume later, with full state preserved across pauses.
A practical example: an AI agent that needs to wait for human approval before continuing. With a job queue, you would split this into two separate jobs and store intermediate state in a database yourself. With Inngest, you call step.waitForEvent() and the function freezes until the event fires — no database required.
SDK support
Inngest ships official SDKs for:
- TypeScript / JavaScript (
inngestnpm package) - Python (
inngest-python) - Go (
github.com/inngest/inngest-go) - Ruby (
inngestgem)
The CLI doubles as a local dev server that mirrors the production execution engine, so local testing behaves identically to production.
Event-driven triggers
Workflows are triggered by events rather than HTTP endpoints. This decouples producers from consumers — any service can emit an event, and Inngest fans out to all subscribed functions. This pattern scales naturally to multi-tenant SaaS where each tenant generates their own events.
Concurrency control
export default inngest.createFunction(
{ id: "process-report", concurrency: 5 },
// ...
);
The concurrency option limits how many instances run simultaneously. Per-tenant concurrency limits are also supported, which is critical for shared infrastructure serving multiple customers.
Practical Evaluation Checklist
- Write and deploy a simple step function to production
- Trigger it via the Inngest event API
- Observe retry behavior by forcing a step failure
- Test
waitForEventwith a manual event send - Check the Inngest dashboard for trace replay
- Evaluate pricing for hosted vs. self-hosted
Security Notes
- Functions run in your own environment (self-hosted or via Inngest Cloud)
- Events are scoped to your workspace with API key authentication
- Sensitive data in function state is not stored by Inngest — only execution metadata
- The CLI dev server runs locally and does not transmit code to Inngest servers
FAQ
Q: Does Inngest require a separate service to run? A: You can use Inngest Cloud (hosted) or self-host the Inngest server. The CLI dev server runs locally for development.
Q: How is this different from Temporal? A: Both offer durable execution, but Inngest is event-driven by design (not workflow-centric), has a first-class HTTP-first API, and a lighter operational footprint. Temporal uses its own workflow definition language; Inngest uses standard functions in your language of choice.
Q: What happens if a step runs for longer than expected? A: Inngest tracks step timeouts and retries steps that exceed configured limits. Long-running steps do not block other steps in the same function.
Q: Is there a free tier? A: Yes — Inngest Cloud has a free tier with usage limits. Self-hosting is fully open source under SSPL.
Q: Can I use my own AI models with Inngest?
A: Yes. Inngest does not mandate a specific AI provider. You call your own model endpoints inside step.run() blocks and wrap the calls with step.score() for observability.
Conclusion
Inngest fills the gap between stateless HTTP functions and full workflow engines like Temporal. Its event-driven model, multi-language SDKs, and built-in observability make it a practical choice for teams building AI agents, background job pipelines, or any process that needs to survive interruptions. The open-source core lets you self-host with no vendor lock-in.
If you need durable execution without deploying a separate workflow cluster, Inngest is worth evaluating.
Related Posts
ai-setup
Recall – Persistent Memory for Claude Code via MCP Hooks
Recall gives Claude Code a permanent memory store that survives session restarts and context compaction. Four hooks capture and restore context automatically — with cloud SaaS or self-hosted options.
2/28/2026
dev-tools
Automotive Skills Suite for AI Engineering
Evaluate Automotive Skills Suite for APQP, ASPICE, HARA, safety-plan, and DIA workflows with setup notes, governance risks, and SME review guidance.
5/28/2026
dev-tools
awesome-agentic-ai-zh Roadmap Guide
Explore awesome-agentic-ai-zh as a Chinese agentic AI learning roadmap, with setup notes, track selection, study workflow, and evaluation guidance.
5/28/2026