Current behavior
Running vercel dev locally, SvelteKit intercepts all requests, including /api/* routes. The Rust serverless functions are never compiled or invoked. SvelteKit’s dev server takes ownership of the entire request
pipeline, so the conventional api/ directory routing that works in production never kicks in.
Expected behavior
/api/* requests should be routed to compiled Rust serverless functions, and all other requests should be served by SvelteKit’s dev server — the same way it works in production on Vercel.
Steps to reproduce
- Create a SvelteKit project with
@sveltejs/adapter-vercel - Add Rust serverless functions in
api/directory (usingvercel_runtime) - Run
vercel dev - Try to access
http://localhost:3000/api/hello— SvelteKit handles it instead of the Rust function
What I’ve tried
- Plain
vercel dev— SvelteKit is detected as the framework and serves everything. Rust functions are ignored. - Adding explicit
builds/functionsin vercel.json — No effect locally, the framework override still takes priority. - Vite proxy — Proxying
/apito another port works for mocking, but doesn’t actually run the Rust binaries, defeating the purpose of e2e local dev.
Project information
- Framework: SvelteKit (
@sveltejs/adapter-vercelv6) - Serverless Functions: Rust (compiled binaries in
api/viavercel_runtime) - vercel.json:
{}(empty, relying on convention-based routing) - Project structure:
demo/
├── api/ ← Rust serverless functions (hello.rs, time.rs, etc.)
├── Cargo.toml ← each .rs file is a [[bin]] target
├── src/ ← SvelteKit app
├── svelte.config.js
├── vite.config.ts
└── package.json
Each Rust function usesvercel_runtime(via a proc macro) and compiles into a standalone binary. In production on Vercel,/api/hello,/api/time, etc. are served by these Rust binaries, and everything else is handled by
SvelteKit. This works perfectly in production.
Question
Is there a supported way to run vercel dev so that both SvelteKit and Rust serverless functions work simultaneously? Or is this a known limitation of vercel dev with framework-detected projects + non-Node serverless
functions?
Currently my workaround is running e2e tests against a deployed preview URL, but local iteration would be much faster.