Skip to main content
Vercel supports Bun, but the deployment model is different from running Redop as a normal long-lived Bun.serve process.

​
The important caveat

Redop’s standard production shape is a Bun HTTP server started with listen({ port, hostname }). Vercel’s Bun support is for Vercel Functions. That means you should not treat Vercel as a drop-in replacement for Railway or Fly.io when you want a persistent Bun server process.

​
When Vercel fits

Use Vercel only if you are intentionally adapting your Redop entrypoint to Vercel’s function model. If you want the standard Redop server shape with a listening port, prefer:

​
Bun on Vercel

Vercel’s Bun runtime is configured in vercel.json: 
{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "bunVersion": "1.x"
}
Vercel Functions expect a function-style entrypoint, typically under an api/ directory, instead of a server that binds directly to PORT.

​
What to avoid

Do not document or deploy this Redop shape as if it were a standard Vercel Function: 
new Redop({
  name: "redop-mcp",
  version: "0.1.0",
}).listen({
  port: Number(process.env.PORT ?? 3000),
  hostname: "0.0.0.0",
});
That is the correct shape for long-running Bun hosting, but not the default Vercel Functions model.

​
Verification guidance

If you still target Vercel, verify these points first:
  • your entrypoint follows the Vercel function model
  • your runtime is configured for Bun
  • your MCP HTTP behavior still works correctly under function execution and streaming limits

​
Recommendation

Choose Vercel only for an intentionally adapted function-based deployment. For the usual Redop production setup, Railway and Fly.io are simpler and more direct.

​
Next