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]

• fix(frontend): entry deduplication #5061
• [slop]feat(frontend): enable compute, add historical logs #5059
• 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: PR #5030 — feat(frontend): allow local->staging tunnel in dev

Summary: This PR adds one line to frontend/vite.config.ts, allowing the Vite dev server to serve requests arriving via the local.staging.rivet.dev hostname. This enables a local-to-staging reverse tunnel workflow where a developer's local Vite dev server is reachable through the staging subdomain.

---

What the change does

// frontend/vite.config.ts, inside server: { ... }
allowedHosts: ["local.staging.rivet.dev"],

Vite's allowedHosts list prevents DNS rebinding attacks by blocking requests whose Host header doesn't match. Adding an entry here is the correct and minimal mechanism for allowing a tunnel to reach the local dev server.

---

Assessment

No functional or correctness issues. The change is scoped exclusively to the server block (local dev), not preview or build, so it has zero effect on production artifacts.

Convention checks (CLAUDE.md):

• TypeScript only — no Rust conventions apply.
• No new imports, no logic changes, no new dependencies.
• The PR title follows conventional commits (feat(frontend): ...). Minor note: since this is purely a developer-experience config tweak rather than a user-facing feature, chore(frontend): ... would arguably be more accurate, but feat is not wrong.

Security:

• allowedHosts is a dev-server-only guard. It does not expose any new network port or service; the developer's machine must already have the tunnel agent running for this to do anything. The domain (local.staging.rivet.dev) matches the project's staging subdomain convention and is not a wildcard, so this is as narrow as it can be.
• The proxy target remains http://localhost:6420. A tunnel arriving via local.staging.rivet.dev still only talks to localhost on the dev machine — no cross-origin risk is introduced.

Potential concern — hardcoded single hostname:

The current list contains exactly one entry. If other developers need different tunnel subdomains (e.g. local-2.staging.rivet.dev for a second team member, or a different pattern in self-hosted setups), they will need another PR. Consider whether this should be driven by an env var:

// Example: VITE_ALLOWED_TUNNEL_HOST=local.staging.rivet.dev
server: {
    allowedHosts: env.VITE_ALLOWED_TUNNEL_HOST
        ? [env.VITE_ALLOWED_TUNNEL_HOST]
        : [],
    ...
}

This is a suggestion, not a blocker — the hardcoded value is fine for now if local.staging.rivet.dev is a shared, stable hostname for this tunnel.

Missing allowedHosts on preview: The preview block also serves on port 43708. If the tunnel is ever used against a vite preview build, it would still be blocked there. This is likely intentional (preview is not a dev workflow), but worth being aware of.

---

Verdict

The change is correct, minimal, and appropriate for its stated purpose. No blocking issues. The env-var suggestion above is the only meaningful follow-up to consider if the tunnel hostname needs to vary per developer.

[jog1t]

Merge activity

• May 15, 7:36 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 15, 7:52 PM UTC: Graphite rebased this pull request as part of a merge.
• May 15, 7:52 PM UTC: @jog1t merged this pull request with Graphite.