MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-66

1.6.7 Inngest cloud + Vercel wiring (MANUAL): resolve Deployment Protection, set signing/event keys, sync preview URL, trigger a preview run

Done
Description

Depends on: 1.6.2

Operational wiring that only a human with dashboard access can do — it requires an Inngest account and the Vercel project settings, neither of which a coding agent can reach. Added because Subtask 1.6.1's spike, by probing the real deployed preview, discovered that /api/inngest (and /) sit behind Vercel Deployment Protection (SSO) and return 401. Inngest's cloud control plane is an unauthenticated external caller, so it hits the same 401 — meaning the Inngest serve route does NOT work on Vercel preview/prod just by setting the signing/event keys. The protection must be bypassed for the control plane first. See PRODECT_FINDINGS.md #30 (sharp edge #8).

Why a manual/human Subtask, not folded into 1.6.2: 1.6.2 is a coding Subtask that lands the SDK + serve route in main; it cannot click buttons in app.inngest.com or vercel.com. This wiring gates 1.6.x going live in preview/prod (in particular 1.6.3, which migrates real password-reset + invite sends to the job runtime — those would silently fail in prod if Inngest can't invoke the serve route). Tracking it as its own dispatchable manual Subtask means it isn't lost when the 1.6.1 spike branch + its docs/findings/inngest-spike.md runbook are deleted.

Steps (runbook):

  • Resolve Deployment Protection for the control plane. Install the official Inngest↔Vercel integration (Vercel → Integrations). It configures Vercel "Protection Bypass for Automation" so Inngest can reach protected previews and auto-syncs the per-push preview URL — the recommended path. Manual alternative: generate a Protection Bypass secret (Vercel → Project → Settings → Deployment Protection → Protection Bypass for Automation) and configure Inngest with it. (Disabling protection entirely is NOT recommended — it weakens preview security.)
  • Get the keys. Inngest dashboard (app.inngest.com) → create / confirm the motir-core app → copy INNGEST_SIGNING_KEY + INNGEST_EVENT_KEY for each target environment.
  • Set the keys in Vercel. Vercel → Project → Settings → Environment Variables → add both, scope Preview (and later Production). Do NOT set INNGEST_DEV in preview/prod. Redeploy so the env takes effect.
  • Verify. Confirm Inngest synced the preview's /api/inngest (now reachable past the bypass), then trigger the example/ping (or, post-1.6.3, a real job's event) from the Inngest dashboard and confirm a run executed in the deployed environment.

Acceptance criteria

  • The Inngest control plane can reach the Vercel preview /api/inngest (no 401) — i.e., Deployment Protection is bypassed for that path/caller.
  • INNGEST_SIGNING_KEY + INNGEST_EVENT_KEY are set in Vercel's Preview scope (and Production before the Story ships to prod); INNGEST_DEV is NOT set in either.
  • A function (the 1.6.1 example.ping or a 1.6.3 real job) is triggered from the Inngest dashboard and observed running in the deployed preview/prod environment.
  • The chosen approach (official integration vs. manual bypass secret) is recorded in docs/jobs.md when 1.6.2 writes it, so the runtime's prod dependency (the Inngest SaaS account + Vercel bypass) is documented.

Context refs

  • This introduces a production SaaS dependency (an Inngest account). The open-source escape hatch — self-hosting the Inngest server — is documented in #30 if cost / lock-in / data-residency ever forces it.
  • Per-push reality: each PR gets a new preview URL + an isolated Vercel-Neon branch DB. The DB doesn't affect Inngest discovery; the changing URL is exactly why the auto-syncing official integration (step 1) beats manual URL re-pointing.