Skip to main content
For production, run redop as an HTTP server. If you are deploying a normal Redop app on Bun, start with Deploy on Bun runtime before choosing a host. Use this shape as your baseline: 
import { Redop } from "redop";

new Redop({
  name: "redop-mcp",
  version: "0.1.0",
}).listen({
  port: Number(process.env.PORT ?? 3000),
  hostname: "0.0.0.0",
  cors: true,
});

​
Production checklist

  • Read PORT from the platform environment
  • Bind to 0.0.0.0
  • Use the HTTP transport
  • Keep secrets in environment variables
  • Expose /mcp/health for readiness and deploy checks

​
Why HTTP is the production path

Hosted platforms expect a network service that listens on a port. That maps directly to Redop’s HTTP transport:
  • POST /mcp handles JSON-RPC requests
  • GET /mcp exposes the SSE stream
  • GET /mcp/health returns a health response
Do not treat stdio as a hosted deployment target. Use stdio for local MCP host integrations.

​
Environment variables

Keep runtime secrets in the platform dashboard or secret store. Typical variables:
  • PORT for the HTTP listener
  • API keys for plugins or downstream services
  • database URLs or service credentials if your tools need them

​
Health checks

Redop mounts a health endpoint automatically: 
GET /mcp/health
Point your host’s health check or readiness probe at that path. A passing 200 response means the process is up and serving HTTP.

​
Platform fit

  • Bun runtime is the shared baseline for running Redop as a Bun HTTP server
  • Railway is the most direct managed-hosting option for a long-running Bun server
  • Fly.io is a strong fit when you want a containerized VM deployment
  • Vercel supports Bun functions, but it is not the same deployment shape as Redop’s usual Bun.serve server

​
Common mistake

Do not hardcode port 3000 in production. Always prefer process.env.PORT and keep 3000 only as a local fallback.