FastMCP Production Manual — 100+ Pages, Deploy, Secure, Monitor

Chapter 1: Architecture & Deployment Blueprint

Map your FastMCP architecture before you write a single line of config. The biggest production failures don't come from bad nginx settings — they come from picking the wrong deployment pattern on day one and discovering it three weeks later, when you've already built around it.

1.1 The FastMCP Deployment Ladder

There is no single "correct" way to deploy a FastMCP server. There's a ladder, and you climb it as your user count and reliability requirements grow. Each rung adds capability and complexity. Climbing too early wastes weeks on infrastructure you don't need; climbing too late means an outage forces the upgrade at the worst possible time.

Rule of thumb: If you can't name the specific requirement pushing you to the next level (more users than one box can handle, a compliance audit, multi-team isolation), you're not ready for it yet. Most teams reading this should target L2 or L3.

L1 — Local dev. You run fastmcp dev, the MCP Inspector opens, you test tools by hand. No TLS, no auth, no persistence. Nothing survives a reboot. L2 — First real deploy. One machine, uvicorn + nginx + TLS, real domain. Handles 3–10 concurrent users, ~$5/month. Chapter 2 lives here. L3 — Hardened. Containerize, add auth, health checks that verify MCP readiness (not just HTTP 200). Chapters 3–6. L4 — Enterprise. K8s, OTEL, RBAC, multi-region. Chapters 5/7/8 reach here. Don't skip rungs: K8s doesn't fix a broken nginx config — it makes it broken in 12 pods instead of 1.

1.2 Critical Architecture Decisions (Get These Right First)

Four decisions shape everything downstream. Each one is hard to reverse once you've built on it.

Decision 1 — Transport: Stdio vs HTTP

Stdio runs the server as a subprocess of a single local client. Perfect for personal tools — no network, no TLS, no auth. HTTP runs the server as a long-lived network service that any number of remote clients connect to. This is what you need the moment the server lives on a different machine than the client.

# Stdio — single local client, launched on demand
mcp.run()  # defaults to stdio

# HTTP — remote, multi-client, production
mcp.run(transport="http", host="0.0.0.0", port=8000)

Use HTTP for production unless you are specifically building a personal, single-machine tool. Everything in Chapters 2–8 assumes HTTP transport.

Decision 2 — mcp.run() vs mcp.http_app()

This is the decision people get wrong most often. mcp.run() starts a built-in server — one line, works in dev, but manages its own single process with no worker pool, no graceful reload. mcp.http_app() returns a standard Starlette ASGI application that you hand to a real ASGI server (uvicorn or gunicorn) which handles workers, restarts, signals, and graceful shutdown.

# Development — built-in server, single process
mcp.run(transport="http", port=8000)

# Production — expose an ASGI app, run under uvicorn/gunicorn
app = mcp.http_app()

# Then: uvicorn server:app --host 0.0.0.0 --port 8000 --workers 4

Use mcp.http_app() in production, always. Chapter 4 (Docker) and Chapter 6 (CI/CD) both assume you're exposing an ASGI app.

Decision 3 — Auth Provider: Bearer vs OAuth

Start with Bearer, upgrade to OAuth when you need Claude/Cursor to connect or need per-user login. Chapter 3 covers both paths in full.

Decision 4 — Hosting

Default to a VPS. A $5 Hetzner box can run a serious production MCP server. Reach for Cloud Run/ECS when you need auto-scale, and for K8s only when a concrete enterprise requirement forces it.

Putting It Together

By the end of this chapter you should be able to answer four questions about your deployment:

1. Which rung? (L1 dev / L2 single box / L3 containerized team / L4 enterprise)
2. Transport? (Stdio for personal, HTTP for everything remote)
3. App entry point? (mcp.http_app() under uvicorn for production)
4. Auth + hosting? (Bearer or OAuth; VPS, serverless, or K8s)

Most teams land on: L2–L3, HTTP transport, mcp.http_app() under uvicorn, Bearer-then-OAuth, on a single VPS. That's a real, defensible production architecture — and it's exactly the path Chapters 2–8 build, step by step.

Want the rest? Chapters 2–8 cover everything below.

Chapter 1 Got You Started. The Other 7 Cover…

Total: ~24h saved across 8 chapters, 100+ pages.

FAQ