Inngest: The Workflow Engine That Runs Functions on Your Infrastructure, Not Theirs
Hook
Most workflow engines want to run your code. Inngest doesn’t—it just calls it over HTTPS, turning your existing infrastructure into a distributed orchestration platform without deploying workers or managing queues.
Context
Building reliable background jobs has always meant choosing between simplicity and capability. Traditional task queues like Celery or Sidekiq are straightforward but require manual state management for multi-step workflows. Workflow engines like Temporal offer sophisticated orchestration but demand dedicated worker infrastructure and learning curve-heavy SDKs. Meanwhile, cloud-native solutions like AWS Step Functions lock you into a vendor ecosystem and make local development painful.
Inngest emerged from a different architectural premise: what if the orchestration platform never executed your code at all? Instead of deploying workers that pull from queues, you write functions that live in your existing HTTP servers—Next.js apps, FastAPI services, Express backends—and Inngest invokes them via webhooks when events trigger. This inversion means zero new infrastructure for most teams, production parity in local development, and the flexibility to deploy functions anywhere that speaks HTTP. The 5,000+ GitHub stars suggest developers are finding value in this model.
Technical Insight
Inngest’s architecture revolves around six components working in concert. When you send an event via inngest.send(), the Event API receives it, authenticates using event keys, and publishes to an internal event stream. The Runner consumes events, matches them against registered function triggers, and schedules runs in a multi-tenant queue with sophisticated flow control. The Executor then invokes your function via HTTPS callback—this is where Inngest diverges from traditional engines. Your code runs on your servers, not Inngest’s.
The real power lives in the step primitive. Here’s how it transforms a fragile script into a durable workflow:
export default inngest.createFunction(
{
id: "import-product-images",
concurrency: {
key: "event.data.userId",
limit: 10
}
},
{ event: "shop/product.imported" },
async ({ event, step }) => {
const s3Urls = await step.run("copy-images-to-s3", async () => {
return copyAllImagesToS3(event.data.imageURLs);
});
await step.run("resize-images", async () => {
await resizer.bulk({ urls: s3Urls, quality: 0.9, maxWidth: 1024 });
});
}
);Each step.run() call appears to create a recovery point in the workflow. According to the README, steps are ‘retried automatically on failure,’ which enables reliable execution of multi-step processes. The step wrapper allows you to break workflows into discrete units that can recover independently. The concurrency configuration ensures no more than 10 image imports run simultaneously per user, preventing resource exhaustion without writing queue management code.
The README mentions waitForEvent as a capability that allows workflows to pause and resume when matching events arrive, though the specific API details aren’t fully documented. This enables patterns like waiting for payment confirmations or user actions without blocking your server resources.
The Dev Server deserves special mention. Running npx inngest-cli@latest dev launches a local Inngest instance with full dashboard UI at localhost:8288. It discovers functions via the same HTTP endpoint your production deployment uses, meaning you test the exact invocation path that production follows. No mocking, no separate local queue infrastructure, no divergence between environments. This production parity eliminates an entire class of ‘works locally but fails in prod’ bugs that plague distributed systems.
Flow control primitives live in function configuration, not application code. The README lists throttling, debouncing, rate limiting, batching, and prioritization as available flow control methods. These patterns typically require custom queue infrastructure or third-party services, but Inngest makes them declarative configuration options in the function definition.
Gotcha
The HTTP callback model introduces latency that in-process workflow engines avoid. Every step execution requires a network round-trip: Inngest calls your function, your function executes the step, returns the result, Inngest checkpoints it, then calls your function again for the next step. For workflows with many steps, this overhead accumulates. If you need very low step-to-step latency or extremely high-frequency workflows, the network overhead may become a bottleneck compared to in-process execution models.
Network accessibility requirements complicate some architectures. Your functions must be reachable via HTTPS from wherever Inngest runs—either the cloud platform or your self-hosted instance. If your infrastructure sits behind strict firewalls or private VPCs without external ingress, you’ll need additional networking configuration: reverse proxies, VPN tunnels, or moving functions to edge-accessible services. The simplicity of ‘just expose an HTTP endpoint’ assumes your security model allows inbound HTTPS, which isn’t universal. Teams with zero-trust architectures or air-gapped environments will face friction that traditional queue-worker models avoid.
Verdict
Use Inngest if you’re building async workflows, background jobs, or event-driven processes where reliability matters more than microsecond latency. It excels when you want orchestration benefits—retries, state management, flow control—without operating queue infrastructure or dedicated worker fleets. Teams already running HTTP services (Next.js apps, Flask/FastAPI APIs, Express servers) can add durable functions with minimal deployment changes. The local dev server’s production parity alone justifies adoption for complex workflows. Skip it if your use case demands extremely low latency between steps, your infrastructure prohibits exposing HTTP endpoints to external callers, or you’re building simple synchronous APIs where orchestration overhead isn’t warranted. Also consider alternatives if you need to process very high volumes of workflow executions where the HTTP callback overhead might become cost-prohibitive.
