feat(frontend): allow local->staging tunnel in dev

[jog1t]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[jog1t]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• chore: regenerate sdk #5036
• feat(frontend): allow creating serverfull instances during onboarding #5035
• feat(frontend): add provider icons #5034
• refactor(forntend): improve providers table #5033
• fix(frontend): missing provider configuration right after adding it #5032
• refactor(frontend): datacenter aware provider configuration #5031
• feat(frontend): allow local->staging tunnel in dev #5030 👈 (View in Graphite)
• refactor(frontend): better gateway errors #5029
• feat(frontend): rbac token notice for the engine #5028
• fix(frontend): build ladle correctly #5027
• feat(frontend): improve runners errors ui #5026
• fix(frontend): 404 navigation issues #5025
• fix(frontend): ns aware navigation #5024
• fix(frontend): navigate only by using actor ids #5023
• feat(frontend): add serverless check when editing the runner config #4961 : 1 other dependent PR (#4964 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

Code Review

Overview

This PR adds allowedHosts: ["local.staging.rivet.dev"] to Vite's dev server config, enabling a reverse tunnel so the local dev server is reachable through a staging subdomain. The change is a single line in the server block of frontend/vite.config.ts.

---

Findings

Correctness — Placement is correct. allowedHosts lives inside server (dev-only) and has no effect on production builds or the preview server. Scoping to a specific hostname rather than allowedHosts: true (all hosts) is the right, minimal approach.

Conventions — Hostname uses rivet.dev (not rivet.gg), consistent with project conventions.

Security — Low risk: Vite's host-header check is the only guard here. Anyone who can route traffic to local.staging.rivet.dev → 127.0.0.1:43708 (e.g. a developer on the same VPN/network) can reach the dev server. Acceptable for a shared staging tunnel, but worth being aware of if the tunnel DNS is broadly resolvable.

Scope — The entry is unconditional across all modes (local, staging, etc.). This is harmless since allowedHosts only validates the Host header and does nothing if traffic is never routed to that domain. But it would be slightly more precise to gate it on the staging mode:

allowedHosts: mode === "staging" ? ["local.staging.rivet.dev"] : [],

This is a minor nit; the current form is acceptable if the tunnel should work in all dev modes.

PR description — The checklist and test description are blank. For a one-line config change there is not much to test, but a brief note on how the tunnel is set up (e.g. which tool routes local.staging.rivet.dev to localhost) would help future readers understand when and why to use it.

---

Summary

The change is correct and safe. The main suggestion is to conditionally apply the host only when mode === "staging" to keep the scope tight, and to fill in the PR description with a brief tunnel setup note.