Skip to main content
Redop is Bun-native, so this is the default production shape to learn first. Use this guide when you want to run Redop as a normal Bun HTTP server on a host that supports long-running processes.

​
Minimal server shape

import { Redop } from "redop";

new Redop({
  name: "redop-mcp",
  version: "0.1.0",
})
  .tool("ping", {
    description: "Health check tool",
    handler: () => ({ ok: true }),
  })
  .listen({
    port: Number(process.env.PORT ?? 3000),
    hostname: "0.0.0.0",
    cors: true,
  });

​
Production rules

  • read PORT from the environment
  • bind to 0.0.0.0
  • use the HTTP transport
  • store secrets in environment variables
  • use /mcp/health for health checks

​
Install and start

Install dependencies with Bun: 
bun install
For a simple production setup, run your entrypoint directly: 
bun run src/index.ts
If your app has a build step, build first and run the output instead: 
bun run build
bun run dist/index.js
Choose one startup path and use it consistently in your host’s start command.

​
Docker baseline

If your host deploys containers, this is a good starting Dockerfile: 
FROM oven/bun:1

WORKDIR /app

COPY package.json bun.lock ./
RUN bun install --frozen-lockfile

COPY . .

EXPOSE 3000

CMD ["bun", "run", "src/index.ts"]
If you build before runtime, change the command to start the built output instead.

​
Verify the app

After the process starts, verify the built-in health endpoint: 
curl http://localhost:3000/mcp/health
You should receive an HTTP 200 response.

​
Where to use this

  • Railway if you want the simplest managed hosting flow
  • Fly.io if you want a containerized VM deployment
Use Vercel only when you are intentionally adapting Redop to a function-based runtime model.

​
Common mistake

Do not assume stdio is interchangeable with HTTP in production. Hosted Bun deployments should expose the HTTP transport unless you are building a local-only integration.