ai-setup 6 min read

Inngest - Durable Workflows Without Infrastructure

Build reliable background jobs and AI agent workflows without extra infrastructure. Automatic retries, flow control, and step-level observability.

By
Share: X in
Inngest durable execution platform

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.md on 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 (inngest npm package)
  • Python (inngest-python)
  • Go (github.com/inngest/inngest-go)
  • Ruby (inngest gem)

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 waitForEvent with 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.