Repository navigation
0.2.0
Any Swift server that listens on a port now runs on Vercel unchanged, with no framework adapters.
This is how Vercel runs standalone Go servers.
VercelBootstrap(new): the function's entrypoint. It starts your app withPORTset, finds
the port it listens on (from/proc, so apps that ignorePORTwork too), and proxies requests
to it. It also implements the Vercel runtime protocol for the app: health checks, internal
header stripping, anendper request (and at101for WebSockets), streaming in both
directions with backpressure, WebSocket tunnels,CRON_SECRETenforcement on cron paths,
SIGTERMforwarding, and crash reporting. Built and deployed byvercel-build.VercelBuildPlugin: builds both binaries and writesvercel-bootstrap.json; the function's
handler,executable, is now the bootstrap, like Vercel's Go builder. Executable products named
executableorbootstrapare rejected (AWS Lambda would run a file namedbootstrapas its
runtime, bypassing Vercel's).VercelRuntimeis now optional and framework-agnostic. Per-request logs andwaitUntiltake the
request'sHTTPFields:Vercel.withRequest(request.headers) { ... }(typically from a
five-line middleware) andVercel.waitUntil(for: request.headers) { ... }. They talk to the
bootstrap overVERCEL_BOOTSTRAP_SOCKET, connecting on first use. Request helpers are
request.headers.vercel.- The package now requires macOS 15 instead of macOS 26.2 (Vapor 5 still requires macOS 26.2).
Breaking changes
- Removed
VercelVapor,VercelHummingbirdandVercelHummingbirdWebSocket. Use
Application()/Application(router:)and.http1WebSocketUpgradedirectly. - Removed
VercelCronMiddleware: the bootstrap enforcesCRON_SECRETon the cron paths from
vercel.json.VercelCron.isAuthorized(_:secret:)remains for other routes. - Removed the in-process runtime API (
VercelRuntimeclass,serverStarted,withRequest(_:)
with anInvocationContext,removeVercelInternalFields): the bootstrap owns the runtime
protocol now. request.vercelis nowrequest.headers.vercel.