fix(cli): pass RIVET_ENDPOINT to supabase edge functions in dev

[jog1t]

• Pass RIVET_ENDPOINT to the Supabase edge function during rivet dev by generating an env file and passing --env-file to supabase functions serve. The Supabase CLI does not forward the parent process environment to the edge runtime worker, so the function previously fell back to loopback and never connected back to the engine.
• Default the engine's advertised URL to http://host.docker.internal:6420 for the Supabase provider, since the edge runtime runs in a container and cannot reach the host on loopback. A user-supplied --env-file still takes precedence.
• Record the engine's effective bind host and public URL to a runtime stamp file when it is spawned, and read it back when a later rivet dev reattaches. This is deterministic and needs no network probing.
• Fail fast when rivet dev --provider supabase would reuse an engine that the stamp shows is bound to loopback only (left over from another provider or an older CLI), since the edge runtime cannot reach it from its container. A freshly spawned engine is known-good and never blocked; an engine with no usable stamp is warned about rather than blocked.
• Warn (without blocking) when reusing an otherwise reachable engine that advertises a different public URL than the current project needs, which the engine would reject with an endpoint mismatch.
• Add the missing deno.json import map to the hello-world-supabase-functions example. Without it Deno cannot resolve the bare rivetkit specifier and every worker fails to boot.
• Document that supabase start must run before rivet dev, and note that the reused engine keeps its endpoint and binding until restarted.
• Move tempfile from dev-dependencies to dependencies.

[claude]

Review: fix(cli): pass RIVET_ENDPOINT to supabase edge functions in dev

Re-reviewed against the latest revision (54b8eb5).

Previously flagged issue is now fixed

• The doc-comment orphaning problem (the EngineProcessManager doc block bleeding into EngineRuntimeStamp because of the missing blank line before the derive) is resolved. Each struct now has its own correctly attached doc comment (EngineRuntimeStamp at rivetkit-rust/packages/engine-process/src/lib.rs:71, EngineProcessManager at :107).

Verified as solid

• check_supabase_engine_reuse runs after start_or_reuse but before plan.spawn(), so a bad reuse (loopback-only stamp) fails before any dev-server child is spawned; the temp env file created in HandlerPlan::resolve is cleaned up via NamedTempFile's Drop on the early return.
• EngineStartup and the Provider matches enumerate every variant explicitly (no _ => fallthrough), matching the repo's enum-matching convention.
• resolve_bind_host is shared between engine_env and the new stamp-writing code, so the two can't drift.
• --env-file=value and --env-file value are both detected in supabase_env_file, with tests for each form.
• Moving tempfile out of dev-dependencies in engine/packages/cli/Cargo.toml is correct now that write_supabase_env_file runs in non-test code.
• Good unit coverage on the new pure logic: binds_loopback_only, resolve_bind_host, pid_is_alive, public_urls_match, and the check_supabase_engine_reuse decision table (spawned / loopback / unknown stamp / URL mismatch).

Minor, non-blocking observations

• write_engine_stamp writes via a direct std::fs::write rather than write-to-temp-then-rename. If two rivet dev invocations start close together, a reader could observe a truncated file mid-write. This fails safe today (read_engine_stamp treats any parse error as None, falling into the "unknown, warn" branch) so it's not a correctness bug, just worth a comment if it's ever intentional.
• pid_is_alive's kill(pid, 0) check has the standard PID-reuse caveat: if the previous engine died and the OS recycles its PID for an unrelated process before the next rivet dev runs, a stale stamp could be treated as live. Low real-world odds for local dev tooling, not worth engineering around here, but worth knowing about if reuse bugs ever get reported.
• engine_stamp_path() is one fixed path under storage_root(), not scoped per endpoint/port. Fine given the current single-engine-per-machine assumption; would need revisiting if the CLI ever supports multiple concurrent engines.
• Edge case: if RIVET_ENDPOINT is set in the parent shell and the user also passes their own --env-file after --, resolve_engine_public_url uses the env var (highest precedence) for the engine's public_url, while HandlerPlan::resolve leaves the user's --env-file untouched (whatever RIVET_ENDPOINT is written there). The engine and the edge function can then end up pointed at two different endpoints. Narrow, and arguably fine as documented "you own it once you pass --env-file" behavior, but worth a doc callout if it trips anyone up in practice.

Docs/examples

• The deno.json import-map addition, README, and supabase.mdx updates read correctly and match the new default behavior (http://host.docker.internal:6420, supabase start prerequisite, the "engine keeps running / RIVET_ENDPOINT changes need a restart" note).

Overall this is a well-scoped, well-tested fix. No blocking issues found in this pass.

[railway-app]

🚅 Deployed to the rivet-pr-5483 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	Jul 24, 2026 at 10:24 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Jul 24, 2026 at 10:10 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Jul 24, 2026 at 10:09 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Jul 24, 2026 at 10:09 pm
ladle	✅ Success (View Logs)	Web	Jul 24, 2026 at 10:03 pm
mcp-hub	✅ Success (View Logs)	Web	Jul 24, 2026 at 10:01 pm