Deploying Inngest to Production

Everything you've built so far has run locally — the Dev Server, the Invoke button, watching runs appear in the dashboard at http://localhost:8288. It all works beautifully on your machine.

Now let's send it to the world.

Deploying Inngest to production involves three things that don't exist in local development: a signing key (so Inngest Cloud can call your app securely), an event key (so your app can send events to Inngest Cloud), and a sync (so Inngest Cloud knows where your functions live). Once those three are in place, your production deployment behaves identically to your local setup — same execution model, same observability, same retry logic — just running at scale.

Let's set them up.

---

Quick Reference

Two environment variables you must set in production:

INNGEST_SIGNING_KEY=signkey-prod-...   # Authenticates Inngest ↔ your app
INNGEST_EVENT_KEY=...                  # Authenticates your app → Inngest

Remove this variable in production:

# INNGEST_DEV=1  ← DELETE this. It routes events to localhost, not Inngest Cloud.

Sync your app after every deploy:

curl -X PUT https://your-app.com/api/inngest

Or use the Vercel / Netlify integration — they sync automatically on deploy.

---

What You Need to Know First

Required reading (in order):

1. Your First Inngest Function — serve endpoint, client setup
2. Local Development with the Inngest Dev Server — understanding the difference between local and cloud mode

You should have:

• An Inngest Cloud account — free tier available
• A deployed application accessible over HTTPS (Vercel, Netlify, Railway, Render, AWS, etc.)
• Your INNGEST_DEV=1 flag set only for local development — not in production

What We'll Cover in This Article

By the end of this guide, you'll understand:

• What signing keys are, why they exist, and how to set them
• What event keys are and how they differ from signing keys
• The three ways to sync your app with Inngest Cloud
• Inngest's environment model: Production, Branch, Custom, and Local
• How to set up branch environments for PR preview deployments
• The Vercel and Netlify integrations — what they automate
• How to verify your production deployment is working correctly
• Signing key rotation — zero-downtime key changes

What We'll Explain Along the Way

• Why INNGEST_DEV=1 must be removed in production
• What "syncing" means and why it's required after every deploy
• Why all branch environments share a single signing key

---

Part 1: The Two Keys

Local development requires no authentication — the Dev Server trusts all requests from your machine. Production is different. Two keys secure the communication between your app and Inngest Cloud, and they serve distinct purposes.

Signing Key — securing Inngest → your app

As Inngest uses signing keys to secure communication between Inngest and your servers. The signing key is a secret pre-shared key unique to each environment. It provides serve endpoint authentication — all requests sent to your server are signed with the signing key, ensuring that they originate from Inngest. Inngest SDKs reject all requests that are not authenticated with the signing key. It also provides replay attack prevention — requests are signed with a timestamp embedded, and old requests are rejected, even if authenticated correctly.

In plain terms: when Inngest Cloud calls your /api/inngest endpoint to execute a function step, it signs that request with your signing key. Your SDK verifies the signature. If the signature is missing or wrong, the request is rejected — preventing anyone else from triggering your functions by calling your endpoint directly.

Where to find it: In the Inngest Cloud dashboard, navigate to your Production environment → Manage → Signing Key.

How to set it:

# In your hosting provider's environment variable settings
INNGEST_SIGNING_KEY=signkey-prod-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The SDK reads this automatically from the environment — no code changes needed. You can set the signing key in your SDK by setting the INNGEST_SIGNING_KEY environment variable. We recommend never hardcoding the signing key in your code.

Event Key — securing your app → Inngest

The event key authenticates your application when it sends events to Inngest Cloud. When your API route calls inngest.send(), it uses the event key to prove it's authorised to publish events to your Inngest environment.

Event Keys are unique keys that allow applications to send events to Inngest. Event Keys should be unique to a given environment (e.g. production, branch environments) and a specific application. Keeping keys separated by application makes it easier to manage keys and rotate them when necessary.

Where to find it: Inngest Cloud dashboard → your environment → Manage → Event Keys → Create Event Key.

How to set it:

INNGEST_EVENT_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Again, the SDK reads this automatically — just set the environment variable.

The key difference

	Signing Key	Event Key
Direction	Inngest → Your App	Your App → Inngest
Purpose	Verifies Inngest's requests are genuine	Authorises your app to send events
Per environment	Yes — one per environment	Yes — one per environment (or app)
Secret?	Yes — never commit to source control	Yes — never commit to source control
SDK env var	INNGEST_SIGNING_KEY	INNGEST_EVENT_KEY

Remove INNGEST_DEV in production

INNGEST_DEV=1 tells the SDK you're in local development mode — it disables signature verification and routes inngest.send() calls to localhost:8288 instead of Inngest Cloud. If this variable is set in your production environment, events will be silently dropped (because localhost:8288 doesn't exist on your production server), and your functions will never run.

# Local .env.local — correct
INNGEST_DEV=1

# Production environment variables — correct (INNGEST_DEV is absent)
INNGEST_SIGNING_KEY=signkey-prod-xxxx
INNGEST_EVENT_KEY=xxxx

# Production environment variables — WRONG
INNGEST_DEV=1             # ← DELETE THIS in production
INNGEST_SIGNING_KEY=...   # Ignored because INNGEST_DEV=1 overrides everything

This is the single most common production deployment mistake. Double-check your hosting provider's environment variable panel before going live.

---

Part 2: Syncing Your App

Once your environment variables are set and your app is deployed, Inngest Cloud needs to know where your functions live. This is called syncing. After deploying your code to a hosting platform, it is time to go to production and inform Inngest about your apps and functions.

Syncing sends Inngest your app's serve endpoint URL and the list of functions registered there. Inngest Cloud stores this so it knows where to call when a function needs to run.

You must resync after every deploy that adds, removes, or changes functions. If you deploy new functions without syncing, Inngest Cloud doesn't know they exist and won't trigger them.

Method 1: Manual sync via the dashboard

1. Log into Inngest Cloud
2. Select your environment (e.g. "Production")
3. Navigate to Apps → "Sync App" or "Sync New App"
4. Paste your serve endpoint URL: https://your-app.com/api/inngest
5. Click "Sync App"

Your app is now synced with Inngest. You'll see it listed in the Apps tab with all its registered functions.

Method 2: Sync via curl (best for CI/CD)

Use the curl command to sync from your machine or automate the process within a CI/CD pipeline. Send a PUT request to your application's serve endpoint.

curl -X PUT https://your-app.com/api/inngest --fail-with-body

The --fail-with-body flag makes curl exit with a non-zero status code if the sync fails, which causes CI/CD pipelines to catch the error rather than silently proceeding.

Add this to the end of your deployment pipeline, after your app is fully live:

# GitHub Actions example — add to your deploy workflow
- name: Deploy to production
  run: # your deploy command here

- name: Sync Inngest functions
  run: |
    # Wait a moment for the deployment to be fully live
    sleep 10
    curl -X PUT https://${{ secrets.PRODUCTION_URL }}/api/inngest --fail-with-body

Before syncing with Inngest, ensure that the latest version of your code is live on your platform. This is because some platforms have rolling deploys that take seconds or minutes until the latest version of your code is live.

Method 3: Platform integrations (automatic)

For Vercel and Netlify, Inngest provides official integrations that handle syncing automatically on every deploy. You install the integration once and never think about it again.

We cover the integrations in Part 4.

---

Part 3: Environments

Inngest accounts all have multiple environments that help support your entire software development lifecycle. Data is isolated within each environment. Event types or functions may share the same name, but their data and logs are fully separated. Each environment uses Event Keys and Signing Keys to securely send data or sync apps within a given environment.

Inngest has four environment types:

Local Environment      ← Dev Server on your machine (no account needed)
       ↓
Branch Environments    ← One per Git branch / PR preview deployment
       ↓
Custom Environments    ← Staging, QA, canary (you create these)
       ↓
Production Environment ← Your live app

Each environment is fully isolated — events sent to production never appear in staging, functions in a branch environment don't affect production.

Production Environment

Your main environment. One signing key, one or more event keys. All functions and events here are live and affect real users.

Environment variables:

INNGEST_SIGNING_KEY=signkey-prod-xxxx
INNGEST_EVENT_KEY=xxxx
# No INNGEST_BRANCH or INNGEST_ENV needed for production

Custom Environments (Staging / QA)

Custom Environments are used to create shared, non-production environments like staging, QA, or canary.

Create a custom environment in the Inngest Cloud dashboard (Settings → Environments → Create Environment). Each custom environment gets its own signing key and event keys — completely isolated from production.

Environment variables for staging:

INNGEST_SIGNING_KEY=signkey-staging-xxxx  # Staging environment's signing key
INNGEST_EVENT_KEY=xxxx                    # Staging event key

Branch Environments

Branch Environments are sandbox environments that enable developers on your team to test changes specific to a current Git feature branch. These are designed to work with platforms that support branch-based deployment previews like Vercel or Netlify.

Here's the elegant part: as Branch Environments are created on-demand, all of your Branch Environments share the same Event Keys and Signing Key. This enables you to use the same environment variables in each of your application's deployment preview environments.

This means you set your branch signing key once in your hosting provider's preview environment settings, and every PR gets its own isolated Inngest environment automatically — no per-branch configuration required.

Environment variables for branch deployments:

// In your Inngest client, pass the branch name dynamically
const inngest = new Inngest({
  id: "my-app",
  env: process.env.BRANCH_NAME, // Vercel sets VERCEL_GIT_COMMIT_REF automatically
});

# Shared across all branch deployments
INNGEST_SIGNING_KEY=signkey-branch-xxxx   # Branch signing key (shared by all branches)
INNGEST_EVENT_KEY=xxxx                    # Branch event key
BRANCH_NAME=${VERCEL_GIT_COMMIT_REF}     # Set by Vercel automatically

Each branch's functions and events appear in the Inngest Cloud dashboard under their own branch environment — isolated from each other and from production.

---

Part 4: Platform Integrations

Vercel

The Inngest Vercel integration automates the entire setup:

1. Installs environment variables automatically — INNGEST_SIGNING_KEY and INNGEST_EVENT_KEY are set in your Vercel project for both production and preview environments
2. Syncs on every deploy — when you deploy to Vercel, the integration automatically syncs your functions with the appropriate Inngest environment

Installation:

1. Go to the Inngest integration page on Vercel Marketplace
2. Click "Add Integration"
3. Select your Vercel team and project
4. Authorise the connection to your Inngest account

After installation, every git push to your main branch deploys your app and automatically syncs your Inngest functions — no manual steps, no curl commands, no forgotten syncs.

One important caveat: To rotate signing keys for Vercel projects, you must manually update the INNGEST_SIGNING_KEY environment variable in your Vercel project. During initial setup, the Vercel integration automatically sets this key, but the integration will not automatically rotate the key for you.

Netlify

The Inngest Netlify integration works similarly — it sets environment variables and syncs on deploy. Install it from the Netlify dashboard under Integrations → search "Inngest".

Other platforms (Railway, Render, Fly.io, AWS, GCP, etc.)

For platforms without a native integration:

1. Set INNGEST_SIGNING_KEY and INNGEST_EVENT_KEY as environment variables in your hosting provider's dashboard
2. Add a post-deploy step that runs curl -X PUT https://your-app.com/api/inngest

Most CI/CD systems (GitHub Actions, GitLab CI, CircleCI) support post-deploy hooks. Here's a GitHub Actions example for a generic deployment:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Deploy to your platform
        run: # your deploy command

      - name: Wait for deployment to stabilise
        run: sleep 15

      - name: Sync Inngest functions
        run: |
          curl -X PUT ${{ secrets.PRODUCTION_APP_URL }}/api/inngest \
            --fail-with-body \
            --retry 3 \
            --retry-delay 5
        env:
          PRODUCTION_APP_URL: ${{ secrets.PRODUCTION_APP_URL }}

The --retry 3 --retry-delay 5 flags tell curl to retry up to 3 times with 5-second delays — useful for platforms with rolling deploys where the new version takes a moment to become available.

---

Part 5: Verifying Your Production Deployment

After deploying and syncing, verify everything is connected correctly.

Check 1: The SDK debug endpoint

curl https://your-app.com/api/inngest

Expected response (truncated):

{
  "message": "Inngest endpoint configured correctly.",
  "hasSigningKey": true, // ← must be true in production
  "hasEventKey": true, // ← must be true in production
  "functionsFound": 4, // ← should match your function count
  "mode": "cloud" // ← must be "cloud", not "dev"
}

Flags to watch:

• hasSigningKey: false → INNGEST_SIGNING_KEY not set
• hasEventKey: false → INNGEST_EVENT_KEY not set
• mode: "dev" → INNGEST_DEV=1 is still set — remove it
• functionsFound: 0 → functions not registered in serve()

Check 2: The Inngest Cloud Apps tab

In the Inngest Cloud dashboard, navigate to your Production environment → Apps. Your app should appear with:

• A green sync status indicator
• The correct number of functions listed
• A recent "Last synced" timestamp

If the sync status shows an error, click the app entry to see the exact error message. Common issues: wrong URL, INNGEST_SIGNING_KEY mismatch, serve endpoint returning non-200.

Check 3: Send a test event from the Cloud dashboard

In Inngest Cloud, navigate to your Production environment → Events → "Test Event". Send a test event with the same payload you've been using locally. Watch the Runs tab for the function execution.

If you see a run appear and complete successfully — you're live. 🎉

Check 4: Trigger from your actual app

Make a real request to your application that fires inngest.send(). In Inngest Cloud, watch the Events tab for the event to appear, then the Runs tab for the function to execute. This is the ultimate verification — the full production path from user action to background function.

---

Part 6: Signing Key Rotation

Signing keys should be rotated periodically or whenever you suspect they may have been exposed. Inngest supports zero downtime signing key rotation if your SDK meets the minimum version: TypeScript 3.18.0, Python 0.3.9, Go 0.7.2.

How zero-downtime rotation works

Zero-downtime rotation uses two keys simultaneously — the current key and a fallback key. During the transition, your SDK accepts requests signed with either key:

Step 1: Current state
  INNGEST_SIGNING_KEY=signkey-prod-OLD
  (no fallback)
  → All requests signed with OLD key ✅

Step 2: Generate a new key in Inngest Cloud dashboard
  → Inngest starts signing NEW requests with the NEW key
  → But also continues to have OLD key for verification

Step 3: Add the new key as current, move old key to fallback
  INNGEST_SIGNING_KEY=signkey-prod-NEW
  INNGEST_SIGNING_KEY_FALLBACK=signkey-prod-OLD
  → SDK accepts requests signed with either NEW or OLD key ✅
  → No downtime during the transition

Step 4: Deploy with new environment variables
  → All in-flight requests finish with OLD key (verified by fallback)
  → All new requests use NEW key

Step 5: Remove the fallback (after all in-flight requests complete)
  INNGEST_SIGNING_KEY=signkey-prod-NEW
  (remove INNGEST_SIGNING_KEY_FALLBACK)
  → Rotation complete ✅

To start the rotation process:

1. Inngest Cloud dashboard → Production environment → Manage → Signing Key
2. Click "Create new signing key"
3. Follow the rotation instructions in the dashboard — it walks you through exactly which variables to update and when

---

Part 7: Environment Variables Reference

Here's the complete reference for all Inngest-related environment variables:

Variable	When to set	What it does
INNGEST_SIGNING_KEY	Production, Staging, Branch	Authenticates requests between Inngest and your app
INNGEST_SIGNING_KEY_FALLBACK	During key rotation only	Accepts both old and new keys simultaneously
INNGEST_EVENT_KEY	Production, Staging, Branch	Authenticates inngest.send() calls to Inngest Cloud
INNGEST_DEV	Local only — =1	Routes events to Dev Server, disables signature verification
INNGEST_BASE_URL	Docker / non-default ports	Points SDK at a non-default Dev Server address

A clean production environment has exactly two Inngest variables: INNGEST_SIGNING_KEY and INNGEST_EVENT_KEY. Everything else is either absent or wrong.

# ✅ Correct production environment
INNGEST_SIGNING_KEY=signkey-prod-xxxx
INNGEST_EVENT_KEY=xxxx

# ✅ Correct local environment (.env.local)
INNGEST_DEV=1

# ❌ Wrong — INNGEST_DEV in production
INNGEST_DEV=1
INNGEST_SIGNING_KEY=signkey-prod-xxxx
INNGEST_EVENT_KEY=xxxx

---

Common Misconceptions

❌ Misconception: Syncing only needs to happen once

Reality: To ensure that your functions are up to date, you need to resync your app with Inngest whenever you deploy new function configurations to your hosted platform. This means every deploy. Adding a new function, changing a trigger, updating retry configuration, renaming a function — all of these require a resync. Without it, Inngest Cloud works from stale function metadata.

The fix: Automate the sync in your CI/CD pipeline with a post-deploy curl command, or use the Vercel/Netlify integration which handles this automatically.

❌ Misconception: Branch environments need their own signing keys

Reality: All Branch Environments within your account share a signing key. This enables you to set a single environment variable for preview environments in platforms like Vercel or Netlify. You configure the shared branch signing key once in your hosting provider's "preview deployment" environment settings, and every PR preview automatically gets its own isolated Inngest environment.

❌ Misconception: Setting INNGEST_DEV=1 in production just disables some features

Reality: INNGEST_DEV=1 puts the SDK into local development mode — it routes all inngest.send() calls to http://localhost:8288. On a production server, there is no localhost:8288. Every event send fails silently, no functions run, and there are no error messages unless you specifically check the SDK response. This is one of the most silent and confusing production failures possible.

❌ Misconception: The signing key authenticates your app sending events

Reality: The signing key is for authentication in the Inngest → Your App direction — it proves that incoming requests to your serve endpoint are genuinely from Inngest. The event key authenticates the Your App → Inngest direction when you call inngest.send(). Two separate keys, two separate directions.

---

Troubleshooting Common Issues

Problem: Functions aren't being triggered in production

Diagnostic sequence:

# 1. Check your serve endpoint is reachable and has keys configured
curl https://your-app.com/api/inngest

# Expected: hasSigningKey: true, hasEventKey: true, mode: "cloud"
# If mode is "dev" → INNGEST_DEV=1 is still set, remove it
# If hasSigningKey is false → INNGEST_SIGNING_KEY not set in your hosting provider

# 2. Check that your app is synced
# Inngest Cloud → Production → Apps → your app should have green sync status

# 3. Check that events are arriving
# Inngest Cloud → Production → Events tab → do events appear after you trigger them?
# If not: INNGEST_EVENT_KEY may be wrong or missing

# 4. Check that functions are registered
# Inngest Cloud → Production → Functions → do your functions appear?
# If not: resync your app

Problem: "Invalid signature" errors in your server logs

Cause: INNGEST_SIGNING_KEY is set but doesn't match the signing key in the Inngest environment you synced to.

Common cause: You synced to the Production environment but your app has a staging or branch signing key set, or vice versa.

Fix: Match the signing key in your environment variables to the environment you synced with. Each environment has its own unique signing key — check the Signing Key tab for the specific environment.

Problem: App synced successfully but new functions aren't appearing

Cause: You deployed code with new functions but didn't resync after the deploy.

Fix:

# After your deploy completes and the new code is live:
curl -X PUT https://your-app.com/api/inngest --fail-with-body

Then refresh the Inngest Cloud Functions tab — the new functions should appear.

Problem: Vercel preview deployments all share the same Inngest environment

Cause: The env option isn't set on your Inngest client, so all preview deployments sync to the same branch environment rather than separate per-branch environments.

Fix: Pass the branch name dynamically:

// inngest/client.ts
export const inngest = new Inngest({
  id: "my-app",
  env: process.env.VERCEL_GIT_COMMIT_REF ?? process.env.NODE_ENV,
  // VERCEL_GIT_COMMIT_REF is automatically set by Vercel to the branch name
});

---

Check Your Understanding

Quick Quiz

1. You deploy a new function to production but forget to resync. What happens when that function's trigger event fires?

Show Answer

Nothing. Inngest Cloud's function registry still shows the old function list from the last sync — the new function isn't registered yet. The event arrives, Inngest checks its registry, finds no matching function, and the event is processed but triggers no runs. The function effectively doesn't exist from Inngest's perspective until you resync.

Check the Events tab in Inngest Cloud — the event will appear there with "0 functions triggered." That's the diagnostic signal that a sync is needed.

2. What's the difference between INNGEST_SIGNING_KEY and INNGEST_EVENT_KEY? Which direction does each secure?

Show Answer

INNGEST_SIGNING_KEY secures the Inngest → Your App direction. When Inngest calls your /api/inngest endpoint to execute a function step, it signs the request with this key. Your SDK verifies the signature — rejecting requests from anyone else who might call your endpoint.

INNGEST_EVENT_KEY secures the Your App → Inngest direction. When your code calls inngest.send(), the SDK uses this key to authenticate the event send to Inngest Cloud.

Two keys, two directions, both required in production.

3. Your staging environment has INNGEST_SIGNING_KEY=signkey-prod-xxxx (the production signing key). What goes wrong?

Show Answer

When Inngest tries to sync your staging app, it authenticates against the production environment (because the signing key identifies the environment). Your staging app's functions get registered in the production environment, not a separate staging environment.

Staging events trigger production-registered functions. Production-registered functions from staging may conflict with or override the real production functions. Data from staging runs appears in your production logs. This is a data isolation failure — potentially serious if your staging environment points at real databases or sends real emails.

Fix: Use the staging environment's signing key for your staging app. Each environment has its own unique signing key — they are not interchangeable.

Hands-On Challenge

Create a production deployment checklist for your app. It should cover every step from "code is merged to main" to "Inngest functions verified live in production."

See a Suggested Checklist

## Inngest Production Deployment Checklist

### Before first deploy (one-time setup)

- [ ] Create an Inngest Cloud account at app.inngest.com
- [ ] Navigate to Production environment → Manage → Signing Key
- [ ] Copy the signing key
- [ ] Set INNGEST_SIGNING_KEY in your hosting provider's production environment variables
- [ ] Navigate to Production environment → Manage → Event Keys → Create Event Key
- [ ] Set INNGEST_EVENT_KEY in your hosting provider's production environment variables
- [ ] Verify INNGEST_DEV is NOT set in production environment variables
- [ ] Install Vercel/Netlify integration (if applicable) for automatic syncing

### Every deploy

- [ ] Code deployed to production
- [ ] Wait for rolling deploy to complete (platform-specific)
- [ ] Run: curl -X PUT https://your-app.com/api/inngest --fail-with-body
      (skip if using Vercel/Netlify integration — they auto-sync)
- [ ] Verify sync in Inngest Cloud → Production → Apps (green status, recent timestamp)

### Verification after deploy

- [ ] GET /api/inngest shows hasSigningKey: true, hasEventKey: true, mode: "cloud"
- [ ] All expected functions appear in Inngest Cloud → Functions tab
- [ ] Send a test event from Inngest Cloud dashboard → verify function runs
- [ ] Check Runs tab — no unexpected failures in last 15 minutes

### Periodic security

- [ ] Rotate signing key every 90 days (or immediately if suspected exposure)
- [ ] Review event keys — deactivate any unused keys

---

Summary: Key Takeaways

• Two required environment variables in production: INNGEST_SIGNING_KEY (Inngest → Your App) and INNGEST_EVENT_KEY (Your App → Inngest). Both are secrets — never commit to source control.
• Remove INNGEST_DEV=1 in production. It routes events to localhost, silently dropping them all.
• Sync after every deploy that adds, removes, or changes functions. Inngest Cloud works from your last sync — stale metadata means functions that don't run.
• Three sync methods: manual via dashboard, curl -X PUT, or automated via the Vercel/Netlify integration.
• Four environment types: Local (Dev Server), Branch (per PR preview), Custom (staging/QA), Production. Each is fully isolated.
• All branch environments share one signing key — configure it once in your preview environment settings and every PR gets its own isolated Inngest environment automatically.
• Zero-downtime key rotation uses INNGEST_SIGNING_KEY_FALLBACK — the SDK accepts both old and new keys during the transition window.
• Verify your deployment with the SDK debug endpoint (GET /api/inngest), the Inngest Cloud Apps tab, and a test event from the dashboard.

---

What's Next?

Your app is now live in production — functions running, events flowing, retries happening automatically.

In Article 13: Observability — Reading Inngest's Run Logs, we close the module with the skill that makes production confidence possible: reading the Inngest dashboard to understand what's happening, diagnosing failures, replaying runs, and knowing at a glance whether your background functions are healthy.

---

Version Information

Tested with:

• inngest: ^4.1.x
• Node.js: v18.x, v20.x, v22.x
• TypeScript: 5.x

Minimum SDK versions for zero-downtime key rotation:

• TypeScript: 3.18.0
• Python: 0.3.9
• Go: 0.7.2

Further reading:

• Signing Keys — Inngest Documentation — full signing key reference including rotation steps
• Creating an Event Key — Inngest Documentation — event key creation and management
• Syncing an Inngest App — Inngest Documentation — sync methods and troubleshooting
• Environments — Inngest Documentation — environment types, branch environments, custom environments
• Vercel Integration — Inngest Documentation — step-by-step Vercel setup
• Netlify Integration — Inngest Documentation — step-by-step Netlify setup
• Environment Variables — Inngest Documentation — complete SDK environment variable reference