PlatformPlatform & operations

Cloud architecture and security

See where Inngest coordinates runs and where your code executes so you can choose the right security controls.

Inngest receives events, matches them to functions, and executes each function as a durable run. Queues separate scheduling from execution, so incoming events don't wait for function code to run.

From event to run

  1. The Event API receives and validates an event, associates it with the correct account and environment, and publishes it to Pub/Sub.
  2. The New Runs service consumes the event and checks for functions with matching triggers.
  3. For each match, New Runs applies the function's flow control configuration, including batching, debounce, and singleton rules.
  4. When the function is ready to start, New Runs creates the run and enqueues its first item on the appropriate queue shard.
  5. Executors consume queue items and invoke your SDK over HTTP or an Inngest Connect connection. Durable queue and run state coordinate later steps, retries, sleeps, and waits.

Lower-latency paths

The standard path is built for throughput: every event can fan out to many functions, and flow control applies before a run starts. When a single request needs to start or finish quickly, use a path that skips part of it:

  • Fast invoke: the Invoke Function API starts one function directly and hands it straight to the executors. It skips Pub/Sub, trigger matching, and the queue, so the run begins sooner. Use events for everything else, since they support fan-out, replay, and webhooks.
  • Checkpointing: checkpointing runs consecutive steps back to back in your app, without a round trip to the executor after each one. It's on by default in the TypeScript v4 SDK.
  • Durable Endpoints: a Durable Endpoint runs inside your own API request and returns its response directly. Inngest stores step results asynchronously and only takes over when a step needs a retry or a wait.

Performance shows how to find which part of the path adds latency and what to change.

Regions and infrastructure

Inngest Cloud runs across two nearby footprints in the eastern United States:

  • AWS us-east-2 (Ohio) hosts customer-facing APIs, control plane services, and supporting data services.
  • Inngest-operated bare metal in Ashburn, Virginia hosts the run scheduling and function execution data plane, including New Runs consumers, queues, constraints, and executors.

The executor coordinates a run but doesn't host your application code. HTTP functions run wherever you deploy your endpoint, and Connect functions run on your connected workers. Calls cross the regional boundary when your infrastructure is outside Ashburn.

Sandboxes are isolated microVMs used within a run, not the host for your function app.

Enterprise isolation

Inngest uses separate infrastructure layers for scheduling, execution, and flow control. This limits noisy-neighbor effects and lets each layer scale independently.

Enterprise customers run on dedicated function execution infrastructure:

  • Queue shards isolate queued function work.
  • Constraint shards isolate concurrency and capacity accounting.
  • Executor capacity consumes work only from the assigned enterprise queue shards.

Dedicated Infrastructure is an enterprise-only add-on, available on request.

Compliance and audits

Inngest is SOC 2 Type II compliant. The company and platform are regularly audited against SOC 2 standards. The platform and SDKs also undergo periodic independent security assessments, including penetration testing and red-team simulated attacks.

To learn more about Inngest's security practices or request a copy of the SOC 2 report, visit the trust center.

Encryption at rest and in transit

Inngest encrypts all data in its databases at rest. Data is also encrypted in transit, including between Inngest's servers and yours. For another layer of control, add encryption middleware and bring your own encryption key.

Signed requests to your app

Every request between Inngest and your app is signed with a signing key, in addition to TLS. The signing key is a pre-shared key, unique to each environment.

SDK endpoint adapters verify the signature for you through serve. Each signature embeds a timestamp, so the SDK rejects old requests and blocks replay attacks.

Signing keys also authenticate your app when it calls the Inngest API, for example to checkpoint runs. Connect workers use them to open a connection to Inngest.

Keep your signing key secret. An exposed key puts your endpoints at risk. You can rotate signing keys with zero downtime.

API keys for scripts and CI

Use API keys for programmatic access to the Inngest REST API, such as custom scripts, tooling, or CI/CD pipelines. Scope each key to a specific environment.

Sign in with SAML

Enterprise users can require SAML to sign in to their account. To turn on SAML:

  1. Ask your account manager for a SAML integration.
  2. Send the configuration your SAML provider requires. This varies by provider and may include a metadata URL, an SSO URL, an IdP entity ID, or an IdP x.509 certificate.
  3. Use the ACS and Metadata URL your account manager sends to configure your provider.
  4. Work with your account manager to map attributes so sign-in works fully.

Once SAML is on, users must sign in with SAML. To learn about enterprise plans, contact the Inngest team.

How app syncs work

Your functions live in your codebase and run on your infrastructure. Inngest syncs your app to read the current function configuration. For apps that use serve on a public HTTP endpoint, Inngest uses one of two methods:

  • Direct sync: Inngest sends a signed PUT request to your endpoint, and your app returns its configuration, including all function config, in the response. This is the default as of TypeScript SDK v3.31.0 and Python SDK 0.4.18.
  • Indirect sync: the default before direct sync, and still available to start a sync from your server. A PUT request to your endpoint starts the handshake. Your app then serializes its configuration and sends it to the Inngest API, authenticating with its signing key. The SDK only sends requests to https://api.inngest.com, unless you configure it for a self-hosted Inngest server.

Connect workers sync their app configuration directly with the Inngest API when they start.

Security best practices

Encrypt sensitive data with middleware

Inngest runs your functions from the event data you send. It also stores the output of each step.run in function state. Both can contain regulated or sensitive data.

If you process sensitive data, Inngest strongly recommends, and sometimes requires, encryption middleware in your SDK. The middleware runs on your servers and encrypts data with a key only you hold:

  • Data in event.data.encrypted is encrypted before it leaves your servers. Inngest can never read it.
  • Step output and function output are encrypted before they leave your servers. Inngest only receives encrypted values and sends function state back to the SDK fully encrypted. The SDK decrypts it on your servers and resumes as usual.
  • The middleware decrypts data automatically when your app receives it.

Your data stays encrypted even if something unexpected happens.

Allow Inngest IP addresses

Inngest makes outbound requests to your app, so add Inngest's IP addresses to your firewall allowlist or security groups. These ranges cover all function invocations and webhook deliveries. Use the complete ranges from these lists:

Store and rotate keys

Store event keys, signing keys, and API keys as secrets, never in source control or browser code. Scope API keys to the intended environment where possible. You can rotate signing, event, and API keys with built-in tools. To rotate signing and event keys for your app, follow the key rotation procedure.