Overview
The same Vercube codebase can be shipped to different hosts (Vercel, AWS Lambda, Azure Functions, and so on). Each guide in this section shows the small amount of wiring that host needs-extra files, env vars, or the @vercube/serverless adapters-so you are not maintaining separate applications per provider.
How routing and configuration work in your app is covered in Core features. Adapter internals for Lambda and Azure are in Serverless.
Default output
The default production output is a Node.js bundle: run vercube build and you get ESM under dist/index.mjs by default (see Configuration for build.entry and build.output).
When you run vercube dev, the CLI uses a development pipeline that stays as close as practical to that production bundle-same decorators, same request path through your app-so behavior in development and after build does not drift unnecessarily.
Choose a platform
| Platform | How Vercube runs there | Guide |
|---|---|---|
| Vercel | Node.js function with a Web fetch handler (no @vercube/serverless) | Deploy to Vercel |
| AWS Lambda | API Gateway event → Request via @vercube/serverless/aws-lambda | AWS Lambda |
| Azure Functions | HTTP trigger → Request via @vercube/serverless/azure-functions | Azure Functions |
@vercube/serverless. For how adapters map events to Request / Response, see the Serverless module overview.