Skip to content

Deploy overview

import { LinkCard, CardGrid } from ‘@astrojs/starlight/components’;

mcify ships one CLI command per supported target. Pick whichever fits your infra:

TargetCommandWhen to use it
Cloudflare Workersmcify deploy cloudflareEdge runtime, scale-to-zero, lowest cold start.
Vercel Edgemcify deploy vercelAlready on Vercel, want preview deploys per branch.
Fly.iomcify deploy flyReal long-running Node, region pinning (default scl).
Railwaymcify deploy railwayPush and go, no Dockerfile to maintain.
Dockermcify deploy dockerSelf-host, ECS, Cloud Run, push to GHCR/ECR.
Kuberneteshelm install ./charts/mcifyAlready on K8s — pair with mcify deploy docker.

The shape of every deploy

Every target follows the same three-step flow:

  1. BuildbuildServer({ target }) for the right runtime (Workers, Node, etc.).
  2. Generate configwrangler.toml / fly.toml / railway.json / vercel.json / Dockerfile.mcify. If the file already exists it’s left alone — your edits survive.
  3. Invoke the target’s CLIwrangler deploy, flyctl deploy, railway up, vercel deploy, docker build. mcify shells out; it doesn’t re-implement the API.

Every command supports --dry-run so you can inspect what would be pushed without actually pushing.

Per-target guides

CI/CD

Drop-in workflow templates live at .github/workflows-templates/ in the repo. Copy whichever target you use into your project’s .github/workflows/ and fill in the secrets each one’s header lists.

Choosing

If you don’t know:

  • Just want it running, free, fast → Cloudflare Workers.
  • Need WebSocket / long-lived connections → Fly or Railway.
  • Already on Vercel → Vercel.
  • Already on K8s → Docker → GHCR + Helm chart.
  • Self-host on a single VPS → Docker.

Every target serves the same POST /mcp endpoint, so MCP clients don’t care which one you picked.