Inngest

Last reviewed Sep 13, 2026 · 824 words

Inngest sits between your application and your queue, and replaces both the queue and the worker fleet with functions that live in your own codebase. Your app sends events, the Inngest server decides which functions to run, and it calls back into your app over HTTP to execute each step, retrying steps that fail and remembering which ones already succeeded. Self-hosting means running that server yourself: one Go binary or Docker image, plus Postgres and Redis, in about 512 MB of RAM. The SDKs, the durable-step model and the local dashboard are the same as the cloud product; some cloud-only conveniences are not.

It is a library first, a server second

Most of Inngest lives in your app. You install an SDK for TypeScript, Python or Go, write functions that look like this, and expose them on a route such as /api/inngest:

export const welcome = inngest.createFunction(
  { id: "send-welcome", retries: 3 },
  { event: "user/signed.up" },
  async ({ event, step }) => {
    const user = await step.run("load-user", () => db.users.find(event.data.id));
    await step.sleep("wait-a-day", "1d");
    await step.run("send-email", () => mailer.send(user.email, "welcome"));
  }
);

Each step.run is checkpointed. If the email provider is down, only that step retries; the user lookup is not repeated, and the one-day sleep costs nothing because the server, not a process, holds the timer. That is the whole pitch: background jobs with the reliability of a workflow engine, written as ordinary functions with no worker process to deploy.

Development needs nothing installed

The dev server is one command:

npx inngest-cli@latest dev -u http://localhost:3000/api/inngest

It runs in memory, discovers your functions, and serves a dashboard on port 8288 where every event and every step execution is visible with inputs, outputs and retries. This is the part of Inngest people fall for, and it is worth trying even if you end up self-hosting nothing, because it changes how you debug a queue.

Production is inngest start plus two databases

The same binary has a start mode that persists state:

inngest start \
  --postgres-uri postgres://inngest:secret@db:5432/inngest \
  --redis-uri redis://cache:6379 \
  --event-key $INNGEST_EVENT_KEY \
  --signing-key $INNGEST_SIGNING_KEY

The event key authenticates your app when it sends events; the signing key lets your app verify that requests to /api/inngest really come from your server. Set both, because an unsigned Inngest endpoint is a remote-execution hole for every function you registered. Point your app at the server with INNGEST_BASE_URL, and put the dashboard on port 8288 behind your proxy with authentication of its own, since the self-hosted UI does not ship with user accounts.

Postgres holds function state and history; Redis holds the queue. Both need to be backed up if you care about in-flight workflows, and a one-day sleep is in-flight state, so treat the Postgres volume the way you treat any database.

What the cloud product keeps

The catalogue's caveat is accurate: the self-hosted server is the execution engine and a basic dashboard. Team accounts with roles, branch environments for preview deployments, long trace retention and the polished metrics views are things the hosted product does and the open-source server does not, or does more plainly. For a solo developer or a small team that is fine. For a company that wants the observability suite without paying, it is a gap you will notice within a month, and the honest answer is that the Apache-2.0 core is designed to make the cloud product attractive, not to replace it.

Where it sits next to Temporal, Hatchet and n8n

Temporal is the heavyweight in this space: stronger guarantees, worker processes you run yourself, a steeper model and a much larger operational footprint. Pick it when workflows run for weeks and correctness is a legal requirement. Hatchet and Trigger.dev are the closest siblings, both open source with a similar function-as-workflow model; Hatchet in particular is a reasonable choice if you want Postgres-only infrastructure. n8n is not a competitor at all despite sharing the automation category: it is a visual tool for people who do not want to write the function, and Inngest is for people who do.

What I'd do

Use the dev server for a week on a real project before deciding anything. If you are a small team shipping a TypeScript or Python app that already has Postgres and Redis, self-host inngest start in the same compose file, set both keys, back up Postgres, and accept the plain dashboard. If you need multi-team access control and trace retention, pay for the cloud tier rather than trying to rebuild it. If you have no application code and just want tasks wired together, you are in the wrong guide; go read the n8n one.