# Weft versus Inngest Inngest is a strong event-driven durable execution platform for teams that want managed orchestration, event fan-out, and serverless-first deployment. Weft is a Bun-native library and server you embed with your application when you want local control over the engine, checkpoint storage, and workflow runtime. External Inngest documentation on this page was checked on June 12, 2026. Claims about Weft link to this repository's source or guides; claims about Inngest link to Inngest's public documentation. | Dimension | Inngest | Weft | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Triggering model | Events can trigger multiple functions and can synchronize with waiting runs via `wait for event` steps. See Inngest's [Events & Triggers](https://www.inngest.com/docs/features/events-triggers). | Application code starts, signals, updates, or schedules workflows directly through the engine and server APIs. Weft is not an event bus; use your own event source when fan-out is the primary requirement. | | Step API | Inngest exposes `step.run()`, `step.sleep()`, `step.sleepUntil()`, `step.waitForEvent()`, `step.waitForSignal()`, `step.invoke()`, and `step.sendEvent()`. See [Inngest Steps](https://www.inngest.com/docs/learn/inngest-steps). | Weft exposes durable generator operations such as `yield* ctx.run(...)`, `yield* ctx.sleep(...)`, `yield* ctx.waitForSignal(...)`, `yield* ctx.review(...)`, `ctx.all()`, `ctx.race()`, sagas, child workflows, and forks. See [Workflows](../guides/workflows.md). | | Execution placement | Inngest runs the orchestration engine outside your app and calls your code through `serve()` HTTP endpoints or persistent `connect()` workers. Its setup guide frames `serve()` as ideal for serverless platforms and `connect()` for container workers. See [Setting up your Inngest app](https://www.inngest.com/docs/learn/serving-inngest-functions). | Weft runs the engine in your Bun process, ships as a library or single binary, and can expose HTTP/WebSocket when you call `serve()`. See [Server Mode](../../README.md#server-mode) and [Single Binary](single-binary.md). | | Per-step handoff | Inngest's step docs state that each step is executed as a separate HTTP request, while `connect()` gives persistent worker-style execution for lower latency. See [Inngest Steps](https://www.inngest.com/docs/learn/inngest-steps) and [Connect](https://www.inngest.com/docs/setup/connect). | Inline Weft workflows do not cross an HTTP boundary between steps; the same engine process drives the generator and writes checkpoints. Remote activity workers are optional and use the `RemoteWorker` protocol. See [Remote Workers](../guides/remote-workers.md). | | Flow control | Inngest has first-class concurrency, throttling, rate limiting, debounce, singleton, priority, and batching controls. See [Flow Control](https://www.inngest.com/docs/guides/flow-control), [Concurrency](https://www.inngest.com/docs/guides/concurrency), [Throttling](https://www.inngest.com/docs/guides/throttling), [Debounce](https://www.inngest.com/docs/guides/debounce), and [Batching](https://www.inngest.com/docs/guides/batching). | Weft has workflow-local composition (`ctx.all`, `ctx.race`, child workflows, sagas) and durable shared-state primitives such as `DurableSemaphore`, but it does not currently provide Inngest-style event-level throttle/debounce/batch controls. See [Parallel Execution](../guides/parallel-execution.md) and [Concurrency](../guides/concurrency.md). | | Human approval | Inngest documents approval waits through `step.waitForEvent()`, which pauses until a matching event arrives or a timeout fires. See [Wait for event](https://www.inngest.com/docs/reference/typescript/v4/functions/step-wait-for-event). | Weft has a review operation: `ctx.review()` persists a review request, emits review events, exposes review list/get/decision APIs, and resumes the workflow with the reviewer decision. See [`ReviewCoordinator`](../../src/core/review/index.ts), [`submitReviewDecisionOperation`](../../src/server/operations/submit-review-decision.ts), and [Human-in-the-Loop Review](../../README.md#human-in-the-loop-review). | | Browser runtime | Inngest docs position functions as hosted application endpoints or worker connections. | Weft's experimental browser runtime runs the core engine in a Web Worker with IndexedDB-backed storage. See [Browser Runtime](browser-runtime.md) and [Service Worker](../guides/service-worker.md). | | Operational ownership | Inngest handles orchestration, state management, retries, and queue infrastructure through its platform or self-hosted engine. See [How Inngest functions are executed](https://www.inngest.com/docs/learn/how-functions-are-executed). | Weft keeps orchestration in your process and storage backend. That gives local control and fixed deployment shape, but today production recovery requires one engine process per durable store. See [Durability Guarantee](durability-guarantee.md) and [Running Weft as a Singleton Service](../guides/singleton-service-deployment.md). | ## When Inngest Is the Better Fit Choose Inngest when event fan-out, serverless-native deployment, managed queue flow control, and platform-owned orchestration are the center of the problem. Its event model and flow-control features are first-class product surfaces. ## When Weft Is the Better Fit Choose Weft when you want the workflow engine inside your TypeScript/Bun application, no external orchestration service in the request path, checkpoint-not-replay recovery, optional browser-side execution, and a durable review primitive that records review requests and decisions as part of the workflow system.