Skip to main content
skillsSource-backed

Inngest Next.js Durable Workflows Skill

Build Inngest-backed Next.js workflows with event triggers, durable steps, local Dev Server testing, API route serving, retries, concurrency, and production deployment review.

Level:advancedType:generalVerified:validated
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://www.inngest.com/docs/getting-started/nextjs-quick-start, https://github.com/inngest/inngest-js
Safety notes
The download URL is Inngest's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows., The official quickstart documents both package installation and a CLI install path for the Dev Server; review shell installers before piping remote scripts into a shell., Inngest functions can send email, charge billing systems, call LLMs, write databases, enqueue follow-up work, and retry failed steps; design idempotency before production use., Do not commit Inngest signing keys, event keys, dashboard tokens, API keys used inside steps, webhook secrets, or copied dashboard values., Confirm the target Inngest environment before syncing functions, sending events, replaying runs, testing webhooks, or invoking workflows from the Dev Server UI., Keep event names and schemas explicit. Broad catch-all events, copied production payloads, and unvalidated event data can trigger unintended work., Review retry policies, concurrency, rate limits, cancellation, durable step behavior, and deployment timeouts before moving request work into asynchronous functions., For AI workflows, document model calls, human approval points, tool side effects, token cost controls, and what happens when a step retries after partial completion.
Privacy notes
Inngest events, function inputs, step outputs, errors, logs, traces, Dev Server runs, and dashboard history can contain user IDs, emails, order IDs, file metadata, prompts, or webhook payloads., Use synthetic payloads for Dev Server invokes, examples, issue reports, screenshots, demos, and AI-assisted troubleshooting., Avoid sending raw payment data, authentication secrets, access tokens, private documents, or full customer records as event payloads; pass stable IDs and fetch data inside authorized server code when possible., Review Inngest, deployment-provider, observability, LLM-provider, email-provider, payment-provider, and AI-assistant retention policies before using real customer data., If workflows call LLMs or third-party APIs, document which event fields leave the app, where outputs are retained, and how retries affect duplicate external requests.
Platform compatibility
claude-code (native-skill), codex (native-skill), windsurf (native-skill), gemini (native-skill), cursor (adapter), cli (manual-context)
Author
oktofeesh1
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-04

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

86

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Package install

Copy-ready — paste the snippet to get started.

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

7 prerequisites to line up before setup. Have accounts and credentials ready first. Includes a review or approval gate.

0/7 ready
Account & credentials1Install & runtime1Configuration1Review & approval1General3

Safety & privacy surface

Safety & privacy surface

8 safety and 5 privacy notes across 4 risk areas. Review closely: credentials & tokens, network access, third-party handling.

4 areas
  • SafetyNetwork accessThe download URL is Inngest's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
  • SafetyNetwork accessThe official quickstart documents both package installation and a CLI install path for the Dev Server; review shell installers before piping remote scripts into a shell.
  • SafetyGeneralInngest functions can send email, charge billing systems, call LLMs, write databases, enqueue follow-up work, and retry failed steps; design idempotency before production use.
  • SafetyCredentials & tokensDo not commit Inngest signing keys, event keys, dashboard tokens, API keys used inside steps, webhook secrets, or copied dashboard values.
  • SafetyNetwork accessConfirm the target Inngest environment before syncing functions, sending events, replaying runs, testing webhooks, or invoking workflows from the Dev Server UI.
  • SafetyGeneralKeep event names and schemas explicit. Broad catch-all events, copied production payloads, and unvalidated event data can trigger unintended work.
  • SafetyNetwork accessReview retry policies, concurrency, rate limits, cancellation, durable step behavior, and deployment timeouts before moving request work into asynchronous functions.
  • SafetyCredentials & tokensFor AI workflows, document model calls, human approval points, tool side effects, token cost controls, and what happens when a step retries after partial completion.
  • PrivacyNetwork accessInngest events, function inputs, step outputs, errors, logs, traces, Dev Server runs, and dashboard history can contain user IDs, emails, order IDs, file metadata, prompts, or webhook payloads.
  • PrivacyGeneralUse synthetic payloads for Dev Server invokes, examples, issue reports, screenshots, demos, and AI-assisted troubleshooting.
  • PrivacyCredentials & tokensAvoid sending raw payment data, authentication secrets, access tokens, private documents, or full customer records as event payloads; pass stable IDs and fetch data inside authorized server code when possible.
  • PrivacyThird-party handlingReview Inngest, deployment-provider, observability, LLM-provider, email-provider, payment-provider, and AI-assistant retention policies before using real customer data.
  • PrivacyNetwork accessIf workflows call LLMs or third-party APIs, document which event fields leave the app, where outputs are retained, and how retries affect duplicate external requests.

Safety notes

  • The download URL is Inngest's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
  • The official quickstart documents both package installation and a CLI install path for the Dev Server; review shell installers before piping remote scripts into a shell.
  • Inngest functions can send email, charge billing systems, call LLMs, write databases, enqueue follow-up work, and retry failed steps; design idempotency before production use.
  • Do not commit Inngest signing keys, event keys, dashboard tokens, API keys used inside steps, webhook secrets, or copied dashboard values.
  • Confirm the target Inngest environment before syncing functions, sending events, replaying runs, testing webhooks, or invoking workflows from the Dev Server UI.
  • Keep event names and schemas explicit. Broad catch-all events, copied production payloads, and unvalidated event data can trigger unintended work.
  • Review retry policies, concurrency, rate limits, cancellation, durable step behavior, and deployment timeouts before moving request work into asynchronous functions.
  • For AI workflows, document model calls, human approval points, tool side effects, token cost controls, and what happens when a step retries after partial completion.

Privacy notes

  • Inngest events, function inputs, step outputs, errors, logs, traces, Dev Server runs, and dashboard history can contain user IDs, emails, order IDs, file metadata, prompts, or webhook payloads.
  • Use synthetic payloads for Dev Server invokes, examples, issue reports, screenshots, demos, and AI-assisted troubleshooting.
  • Avoid sending raw payment data, authentication secrets, access tokens, private documents, or full customer records as event payloads; pass stable IDs and fetch data inside authorized server code when possible.
  • Review Inngest, deployment-provider, observability, LLM-provider, email-provider, payment-provider, and AI-assistant retention policies before using real customer data.
  • If workflows call LLMs or third-party APIs, document which event fields leave the app, where outputs are retained, and how retries affect duplicate external requests.

Prerequisites

  • Next.js App Router project or migration branch with a known package manager.
  • Inngest account or local-only Dev Server plan, plus permission to create or connect the target Inngest app.
  • Decision on stable SDK usage versus any beta SDK documentation path before pinning package versions.
  • `INNGEST_DEV`, signing keys, event keys, and deployment environment variables managed through local, preview, staging, and production secret configuration.
  • Inventory of existing API routes, webhooks, cron jobs, queue workers, server actions, form submissions, and background jobs that may send events.
  • Event naming, payload shape, idempotency key, retry, concurrency, and failure-handling plan for each workflow.
  • Deployment-provider limits for route runtime, request duration, background execution, and webhook reachability.

Schema details

Install type
package
Reading time
8 min
Difficulty score
78
Troubleshooting
Yes
Breaking changes
No
Source repository stats
Scope
Source repo
Skill and platform metadata
Skill type
general
Skill level
advanced
Verification
validated
Verified at
2026-06-04
Retrieval sources
https://www.inngest.com/docs/getting-started/nextjs-quick-starthttps://www.inngest.com/docs/reference/typescript/introhttps://www.inngest.com/docs/learn/serving-inngest-functionshttps://www.inngest.com/docs/learn/inngest-functionshttps://github.com/inngest/inngest-js
Tested platforms
ClaudeCodexWindsurfGeminiCursorGeneric AGENTS
PlatformSupportInstall path
claude-codeNative.claude/skills/<skill-name>/SKILL.md
codexNative.agents/skills/<skill-name>/SKILL.md
windsurfNative.windsurf/skills/<skill-name>/SKILL.md
geminiNative.gemini/skills/<skill-name>/SKILL.md or .agents/skills/<skill-name>/SKILL.md
cursorAdapter.cursor/rules/<skill-name>.mdc
cliManualAGENTS.md or tool-specific context file
Full copyable content
# Trigger
"Apply the Inngest Next.js durable workflows skill to this app."

# Required output
1) Current Next.js, route, webhook, job, and event inventory
2) Inngest client, function, trigger, serve-route, and Dev Server plan
3) Retry, concurrency, idempotency, deployment, and observability checklist
4) Safety, privacy, event payload, secret, and rollback notes

About this resource

Knowledge Freshness

This skill is based on Inngest's official Next.js quickstart, TypeScript SDK reference, serving-functions docs, Inngest functions docs, and inngest/inngest-js repository reviewed on 2026-06-04. The current Next.js quickstart installs inngest, can run local development with INNGEST_DEV=1, uses the Inngest Dev Server at localhost:8288, creates an Inngest client, serves functions through a Next.js App Router route with serve from inngest/next, registers functions on /api/inngest, and sends events with inngest.send().

Retrieval Sources

Prefer the live Inngest docs and official JavaScript SDK repository over model memory for package versions, SDK v3/v4 differences, serve handler signatures, Dev Server behavior, event schemas, retry controls, concurrency controls, checkpointing, and deployment guidance.

Scope Note

Use this skill for event-driven Inngest workflows in Next.js applications. It is not a generic queue architecture guide, not a replacement for product-specific workflow design, and not permission to replay production events or migrate critical background jobs without an explicit rollout plan.

Core Workflow

  1. Inventory the current Next.js version, router mode, package manager, /src usage, API routes, server actions, route handlers, webhooks, cron jobs, background workers, queue libraries, and deployment provider.
  2. Identify work that should move out of request/response paths: email sends, file processing, AI model calls, enrichment jobs, webhook fan-out, imports, notifications, scheduled tasks, long-running retries, or human approval workflows.
  3. Choose the SDK path deliberately. Confirm whether the project will use the stable package path from the quickstart or a beta TypeScript SDK path before pinning versions, imports, and migration steps.
  4. Add inngest with the project package manager and document local, preview, staging, and production environment variables, including INNGEST_DEV, event keys, signing keys, and any provider secrets used inside steps.
  5. Create a server-side Inngest client module with a stable app ID, environment naming plan, logging expectations, and shared event type definitions.
  6. Create the App Router serve endpoint at the intended /api/inngest route using serve from inngest/next, and register only reviewed functions in the functions array.
  7. Model each event with a name, versioning policy, payload schema, producer, consumer function, idempotency key, authorization boundary, and retention notes.
  8. Write functions with small durable steps. Use step.run() for side effects, make step names stable, and avoid hidden work that cannot be retried or observed cleanly.
  9. Add failure behavior deliberately: retries, cancellation, rate limits, concurrency, debouncing, singleton behavior, priority, or manual intervention where the workflow requires it.
  10. Run the Inngest Dev Server locally, invoke functions with synthetic payloads, inspect the Runs view, and confirm step outputs, logs, retries, and event history before connecting production sources.
  11. Wire producers with inngest.send() from route handlers, server actions, webhook handlers, cron triggers, or domain-service code after validating payloads and authorization.
  12. Review deployment settings for route runtime, duration limits, checkpointing, webhook reachability, environment sync, observability, rollback, and replay safety.

Required Inputs

  • Next.js version, router mode, package manager, deployment provider, and whether the project uses a /src directory.
  • Existing background-job, queue, cron, webhook, event-bus, and async task patterns.
  • Target Inngest account, app, environment, local Dev Server strategy, and function sync path.
  • Event catalog with names, producers, payload fields, schema validation, idempotency keys, and expected consumers.
  • Side-effect inventory for every function, including databases, emails, payments, LLMs, webhooks, file storage, notifications, and third-party APIs.
  • Retry, cancellation, concurrency, rate-limit, timeout, and failure-routing expectations for each workflow.
  • Observability, logging, alerting, replay, rollback, and incident-response expectations for production functions.

Production Rules

  • Keep Inngest keys, signing secrets, API keys, provider tokens, and database credentials in server-only secret stores. Never expose them through client bundles, screenshots, issue comments, or AI prompts.
  • Treat event payloads as public-to-the-workflow data. Prefer compact IDs and server-side lookups over raw customer records, access tokens, payment data, private documents, or full webhook bodies.
  • Make side-effecting steps idempotent before enabling retries or replay. Emails, billing changes, external tickets, LLM calls, and database writes need duplicate protection.
  • Validate event payloads before work begins. Do not trust producers, user-controlled API routes, webhook bodies, or Dev Server test payloads.
  • Keep function registration explicit. A serve route with stale, missing, or accidental functions can hide production work or expose workflows that should not be callable.
  • Separate local, preview, staging, and production Inngest environments. Do not send test events into production or sync experimental functions without a rollback path.
  • Review deployment timeouts and route runtime limits before depending on checkpointing or multi-step functions on serverless platforms.
  • Add monitoring for failed runs, stuck retries, high event volume, rate-limit pressure, external API errors, and unexpectedly expensive AI workflow steps.

Compatibility

Native

  • Claude Code / Claude: use as a reusable Agent Skill for designing, implementing, reviewing, and operating Inngest workflows in Next.js apps.
  • Codex/OpenAI workflows: use as SKILL.md-style instructions when editing Next.js codebases that add Inngest functions, event producers, or deployment-readiness checks.

Manual Adaptation

  • Cursor, Windsurf, Gemini, and Generic AGENTS files: adapt the trigger, workflow, safety notes, privacy notes, and output contract into repository rules for background-job and event-driven workflow work.

Output Contract

  1. Source evidence: Inngest docs and repository URLs reviewed, with date.
  2. Inventory: Next.js routes, async work, webhooks, queues, cron, current background jobs, deployment constraints, and data sensitivity.
  3. Implementation plan: package install, SDK version decision, client module, serve route, function files, event producers, schemas, steps, and tests.
  4. Safety and privacy review: event payloads, secrets, retries, idempotency, replay risk, logs, third-party calls, AI calls, and retention.
  5. Validation plan: local Dev Server invocation, synthetic payloads, route smoke tests, failed-run behavior, retry behavior, and production sync checks.
  6. Rollout plan: environment separation, function sync, monitoring, alerting, rollback, replay policy, and owner sign-off.

Troubleshooting

  • No functions appear in the Dev Server: confirm INNGEST_DEV=1, the Next.js dev server is running, /api/inngest is reachable, and the serve handler registers the intended functions.
  • Events send but runs do not start: check event names, trigger names, function registration, signing/environment config, and whether the event went to the expected local, preview, staging, or production environment.
  • Function retries duplicate side effects: add idempotency checks around email sends, external API writes, payments, ticket creation, and database mutations before enabling broad retry or replay behavior.
  • Serverless route times out: review deployment-provider limits, maxRuntime or route duration settings where supported, function step structure, and whether long work belongs in durable steps instead of one large request.
  • Logs expose sensitive payloads: redact event data, step outputs, errors, traces, and prompt snippets before sharing logs with AI assistants, issues, screenshots, or observability vendors.

Duplicate Check

  • No existing upstream content file uses the inngest-nextjs-durable-workflows slug or official Inngest documentation/repository URLs.
  • Generic background-job, workflow, and Next.js entries remain distinct because this skill is specifically scoped to Inngest's Next.js App Router serve route, event triggers, durable steps, Dev Server review, and production Inngest deployment safety.

Editorial Disclosure

This is a source-backed community content entry submitted by oktofeesh1. There is no paid placement, affiliate link, sponsorship, or maintainer-verified package artifact attached to this listing.

Source citations

Add this badge to your README

Show that Inngest Next.js Durable Workflows Skill is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/skills/inngest-nextjs-durable-workflows.svg)](https://heyclau.de/entry/skills/inngest-nextjs-durable-workflows)

How it compares

Inngest Next.js Durable Workflows Skill side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field

Build Inngest-backed Next.js workflows with event triggers, durable steps, local Dev Server testing, API route serving, retries, concurrency, and production deployment review.

Open dossier

Build Convex-backed Next.js App Router applications with typed backend functions, reactive queries, client providers, realtime UI, data imports, and production deployment review.

Open dossier

Add Better Auth to a Next.js App Router project with API route handlers, database-backed sessions, client helpers, protected route checks, and production auth safety review.

Open dossier

Add Clerk authentication to a Next.js App Router project with middleware, route protection, session-aware UI, environment hygiene, and production auth safety checks.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
Submitteroktofeesh1oktofeesh1oktofeesh1oktofeesh1
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
Brand
Categoryskillsskillsskillsskills
SourceSource-backedSource-backedSource-backedSource-backed
Authoroktofeesh1oktofeesh1oktofeesh1oktofeesh1
Added2026-06-042026-06-042026-06-042026-06-04
Platforms
Harness
Source repo
Safety notesThe download URL is Inngest's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. The official quickstart documents both package installation and a CLI install path for the Dev Server; review shell installers before piping remote scripts into a shell. Inngest functions can send email, charge billing systems, call LLMs, write databases, enqueue follow-up work, and retry failed steps; design idempotency before production use. Do not commit Inngest signing keys, event keys, dashboard tokens, API keys used inside steps, webhook secrets, or copied dashboard values. Confirm the target Inngest environment before syncing functions, sending events, replaying runs, testing webhooks, or invoking workflows from the Dev Server UI. Keep event names and schemas explicit. Broad catch-all events, copied production payloads, and unvalidated event data can trigger unintended work. Review retry policies, concurrency, rate limits, cancellation, durable step behavior, and deployment timeouts before moving request work into asynchronous functions. For AI workflows, document model calls, human approval points, tool side effects, token cost controls, and what happens when a step retries after partial completion.The download URL is Convex's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. `convex dev` logs in, creates or connects a cloud dev deployment, writes deployment URLs, and syncs backend functions; confirm the target account and project first. Treat `convex import`, migrations, table rewrites, backfills, deletes, and scheduled functions as data-mutating operations that need environment confirmation. Do not commit Convex deployment secrets, auth provider secrets, API keys for actions, webhook secrets, or copied dashboard values. Keep client-exposed values such as `NEXT_PUBLIC_CONVEX_URL` separate from server-only secrets used by actions, auth providers, integrations, or external APIs. Review generated APIs, table indexes, pagination, and query fan-out before shipping realtime screens that could overload clients or expose broad datasets. When actions call external services or LLM APIs, add timeout, retry, logging, rate-limit, and secret-handling guidance before production use.The download URL is Better Auth's external source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. Do not commit Better Auth secrets, OAuth provider secrets, database URLs, email-provider credentials, API-key plugin secrets, or copied dashboard values. Run schema generation or migrations only against the intended database environment; auth tables, sessions, accounts, and verification records are production-critical. Treat route protection as server-side authorization work. UI hiding, optimistic middleware redirects, or cookie existence checks are not full access control. Review `proxy.ts` or `middleware.ts` behavior by Next.js version before relying on database-backed session checks inside request middleware. Keep OAuth callback URLs, base URLs, trusted origins, and cookie settings environment-specific to avoid broken login loops or cross-environment session confusion. Track Better Auth release notes and security advisories before introducing auth flows or enabling advanced plugins in production. Add rollback steps before replacing an existing auth provider because user, account, session, and verification tables can affect active logins.The download URL is Clerk's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. Clerk middleware does not protect routes by default; require an explicit protected-route matcher before assuming a page, API route, or tRPC endpoint is private. Do not commit `CLERK_SECRET_KEY`, webhook signing secrets, OAuth provider secrets, or copied dashboard values to source control, issue comments, screenshots, or chat transcripts. Review middleware matchers carefully. A broad matcher can affect static assets and public routes, while a narrow matcher can leave sensitive routes unauthenticated. Treat organization roles, custom permissions, and metadata checks as authorization logic that needs tests, not just UI hiding. Webhook handlers can mutate user, membership, subscription, and organization state. Make handlers idempotent and verify signatures before processing events. Confirm production domains and redirect URLs before deploy; wrong origins can break sign-in, leak users into the wrong environment, or create confusing callback loops.
Privacy notesInngest events, function inputs, step outputs, errors, logs, traces, Dev Server runs, and dashboard history can contain user IDs, emails, order IDs, file metadata, prompts, or webhook payloads. Use synthetic payloads for Dev Server invokes, examples, issue reports, screenshots, demos, and AI-assisted troubleshooting. Avoid sending raw payment data, authentication secrets, access tokens, private documents, or full customer records as event payloads; pass stable IDs and fetch data inside authorized server code when possible. Review Inngest, deployment-provider, observability, LLM-provider, email-provider, payment-provider, and AI-assistant retention policies before using real customer data. If workflows call LLMs or third-party APIs, document which event fields leave the app, where outputs are retained, and how retries affect duplicate external requests.Convex can store user records, app data, realtime query results, auth identifiers, scheduled job state, file metadata, logs, and action inputs or outputs. Client queries, browser traces, app logs, error trackers, screenshots, and AI prompts can expose document IDs, user IDs, table names, deployment URLs, or sampled records. Use synthetic seed data for examples, imports, demos, issue reports, screenshots, and AI-assisted troubleshooting. Review Convex, auth-provider, deployment-provider, analytics, external API, and AI-assistant retention policies before using real customer data. If Convex actions call LLMs, payment systems, email providers, or webhooks, document what user data leaves Convex and where it is retained.Better Auth handles user identity, email addresses, password-auth state, OAuth profile data, sessions, cookies, accounts, verification tokens, and plugin-specific user data. Application logs, error trackers, request traces, AI prompts, and screenshots can retain user IDs, emails, callback URLs, cookies, session state, or OAuth provider details. Use synthetic users and test OAuth applications for examples, demos, issue reports, screenshots, and AI-assisted troubleshooting. If organization, API key, two-factor, passkey, or SSO plugins are enabled, treat membership, roles, credentials, and device metadata as sensitive authorization data. Review Better Auth, database, deployment-provider, analytics, email-provider, and AI-assistant retention policies before using real customer identity data.Clerk processes user identity, email addresses, sessions, cookies, authentication factors, OAuth profile data, organization membership, and optional user metadata. Application logs, error reports, webhook payloads, request traces, and AI chat transcripts can retain user IDs, email addresses, session state, redirect URLs, or organization names. Keep public examples synthetic. Do not paste real Clerk keys, dashboard screenshots, webhook payloads, user records, or organization metadata into prompts or PRs. Review Clerk, deployment-provider, analytics, and AI-assistant retention policies before using real customer identity data in troubleshooting sessions. If custom metadata stores roles, billing flags, internal account IDs, or entitlement data, treat it as sensitive authorization data and avoid exposing it client-side unless intended.
Prerequisites
  • Next.js App Router project or migration branch with a known package manager.
  • Inngest account or local-only Dev Server plan, plus permission to create or connect the target Inngest app.
  • Decision on stable SDK usage versus any beta SDK documentation path before pinning package versions.
  • `INNGEST_DEV`, signing keys, event keys, and deployment environment variables managed through local, preview, staging, and production secret configuration.
  • Next.js App Router project or migration branch with a known package manager.
  • Convex account access and permission to create or use the target Convex project and deployment.
  • `NEXT_PUBLIC_CONVEX_URL` and any Convex deployment environment variables managed through local, preview, staging, and production secret configuration.
  • Data model plan for Convex tables, indexes, generated API functions, and client query/mutation usage.
  • Next.js App Router project or migration branch with a known package manager.
  • Database choice and adapter plan, such as Drizzle, Prisma, MongoDB, or Better Auth's built-in Kysely-backed flow.
  • Local, preview, staging, and production secret-management path for Better Auth secrets, OAuth client IDs, and OAuth client secrets.
  • Route map that separates public pages, authenticated pages, API routes, server actions, admin routes, and organization-scoped areas.
  • Next.js App Router project or migration branch.
  • Clerk account and application for the target environment.
  • `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` and `CLERK_SECRET_KEY` available through local and deployment environment configuration.
  • Route map that separates public pages, protected app pages, API routes, and admin or organization-scoped areas.
Install
pnpm add inngest
pnpm add convex
pnpm add better-auth
pnpm add @clerk/nextjs
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.