Skip to main content
A deployed MCP App is a server on a public URL: hosts connect to https://your-domain.com/mcp and the built views are served from the same origin. Two commands take it there:
  • skybridge build compiles the views and the server into dist/
  • skybridge start runs the result with NODE_ENV=production: pre-built assets on /assets, the MCP server on /mcp, dev tooling excluded
Run them on any Node.js-compatible infrastructure, or pick a platform that automates them:

​
Alpic

Alpic is the preferred deployment target: a cloud platform built for MCP Apps, by the company behind Skybridge. Deployed apps get MCP analytics, logs, insights, and a public playground. Deploying is free, and one command away from any Skybridge project: 
npm run deploy
For continuous deployment, push your app to GitHub and connect the repository from app.alpic.ai: every commit then ships automatically.
Alpic also ships its own MCP App to manage your deployments from any MCP client: connect to https://mcp.alpic.ai/mcp.

​
Cloudflare Workers

Skybridge runs on Cloudflare Workers via Wrangler and the nodejs_compat runtime. Static assets (your built views) are served by Cloudflare’s edge directly; the worker handles /mcp traffic and any other dynamic routes. Add a wrangler.jsonc at your project root:
wrangler.jsonc
{
  "name": "your-skybridge-app",
  "main": "dist/__entry.js",
  "compatibility_date": "2025-09-01",
  "compatibility_flags": ["nodejs_compat"],
  "assets": { "directory": "dist/assets" },
  "define": {
    "process.env.NODE_ENV": "\"production\""
  }
}
Each setting is load-bearing:
  • compatibility_date >= 2025-09-01 and nodejs_compat: enable cloudflare:node’s httpServerHandler, which Skybridge uses to bridge the Express app to the Workers fetch event.
  • assets.directory: points at the views built by skybridge build. Cloudflare serves these at the edge before requests reach your worker.
  • define.process.env.NODE_ENV: forces production mode even under wrangler dev. Without it, wrangler defaults to development locally and Skybridge’s dev tooling (Vite, the DevTools server) gets pulled into the worker bundle, where neither runs.
Then build and deploy: 
npm run build
npx wrangler deploy
wrangler dev runs your worker in workerd on your machine, the same runtime as production, not a Node.js fallback. Use skybridge dev for fast iteration with HMR; use wrangler dev to validate the production worker bundle before shipping.

​
Docker

Projects scaffolded with npx skybridge create include a multi-stage Dockerfile, so you can self-host on any container platform: 
docker build -t my-app .
docker run -p 3000:3000 my-app
The package manager is detected from the lockfile (package-lock.json, yarn.lock, or pnpm-lock.yaml). Bun and Deno are not supported yet: adapt the build stage inside the Dockerfile.

​
Vercel

skybridge build emits a Build Output API tree under .vercel/output/: a bundled serverless function, the static asset tree, and the routing config. No vercel.json required. 
npm run build
npx vercel deploy --prebuilt
.vercel/ is gitignored by Vercel CLI convention, so the build artifacts stay out of your tracked working tree.

​
Path Prefixes

Skybridge can run under a path prefix like https://your-domain.com/v1/mcp, reading it from the x-forwarded-prefix header to serve assets under that path. This is how you run several versions of one app on a shared domain.