vercel_runtime

vercel_runtime is the Rust crate that powers Vercel’s serverless and Fluid Compute functions, giving Rust developers a first-class way to handle HTTP requests directly inside Vercel’s build and deployment pipeline. It wraps a hyper-based request/response cycle with optional axum and actix-web adapters, so teams can bring existing web-framework code and run it as a Vercel Function with minimal glue code.

Beyond basic request handling, the crate manages background work via a waitUntil-style awaiter, forwards structured logs and metrics over a Unix-socket IPC channel to Vercel’s runtime host, and exposes typed request/response bodies so Rust’s compile-time guarantees carry through to the edge of the HTTP layer. It is maintained directly inside the vercel/vercel monorepo alongside the Vercel CLI and platform SDKs.

What You Get

• A run! macro / run entrypoint that wires a Rust async handler into Vercel’s Lambda-style function contract
• Optional axum feature exposing a VercelLayer tower middleware for dropping an existing Axum app onto Vercel
• Optional actix feature for running Actix Web applications as Vercel Functions
• An Awaiter for scheduling background (waitUntil) work that completes after the response is sent
• Structured logging and metrics forwarded over a Unix-domain-socket IPC channel to the Vercel runtime host
• Typed Error and ResponseBody types built on serde/serde_json for ergonomic JSON handling

Common Use Cases

• Deploying a Rust HTTP API as a Vercel serverless function without managing your own container or server
• Porting an existing Axum or Actix Web application to Vercel with a thin adapter layer instead of a rewrite
• Building latency-sensitive endpoints (webhooks, edge logic) that benefit from Rust’s performance on Vercel’s Fluid Compute runtime
• Running background cleanup or logging work after a response has already been returned to the client via waitUntil

Under The Hood

Architecture: The crate centers on a run entrypoint (src/lib.rs) that stands up a hyper http1 connection over a Unix socket, dispatching each request through a tower::Service. A process-global Awaiter (src/awaiter.rs), guarded by lazy_static, collects waitUntil-style background futures so they can be drained once after the response is flushed. On Unix targets, a dedicated IPC module (src/ipc/core.rs, src/ipc/log.rs, src/ipc/metric.rs, src/ipc_utils.rs) opens a UnixStream to send StartMessage/EndMessage/LogMessage frames to the Vercel runtime host, giving the platform visibility into invocation lifecycle, logs, and metrics without the function author writing any of that plumbing. Optional axum and actix submodules (src/axum/mod.rs, src/actix/mod.rs) adapt each framework’s native service traits onto the same hyper-based request pipeline. Tech Stack: Rust 2024 edition; core dependencies are hyper 1.x, hyper-util, tower, tokio (full features), http-body/http-body-util, tokio-stream, serde/serde_json, base64, and lazy_static; libc is pulled in for Unix-only cfg blocks; axum 0.8 + axum-streams and actix-web 4/actix-rt/actix-http are gated behind Cargo features so consumers only compile what they use. Code Quality: The crate has no dedicated unit or integration test suite under crates/vercel_runtime; correctness is instead exercised indirectly through the example apps under examples/axum and examples/actix-web and through Vercel’s own deployment/build pipeline (this is the repo’s monorepo-wide pattern — most testing lives in the TypeScript CLI packages, not the Rust crate). Code is organized into small, single-responsibility modules (types, awaiter, ipc, framework adapters) with #[cfg(unix)] used to cleanly separate platform-specific IPC logic from the cross-platform request path. API Design: The public surface is deliberately small — a run entrypoint, a Request/Response type alias pair, and an Error type — with framework interop handled by opt-in Cargo features (axum, actix) rather than separate crates, so a project pulls in only the adapter code it needs. The axum integration in particular reduces adoption friction to adding a single VercelLayer to an existing Router, and the example projects (examples/axum/src/main.rs) show idiomatic framework code with almost no Vercel-specific boilerplate.