Enterprise MCP server deployment

High availability: replicas and health-check gates

The minimum HA configuration for a production MCP server is two replicas in separate availability zones with a health-checking load balancer. The critical detail: configure the load balancer health check to probe the MCP protocol endpoint, not just the HTTP port.

# Nginx upstream with MCP-aware health check (Nginx Plus / OpenResty)
upstream mcp_search {
    zone mcp_search 64k;
    server mcp-search-1.internal:8080 max_fails=2 fail_timeout=10s;
    server mcp-search-2.internal:8080 max_fails=2 fail_timeout=10s;
    keepalive 32;
}

# Custom health check: send MCP initialize request
# (Nginx Plus feature — community Nginx uses passive checks only)
match mcp_health {
    send "POST /mcp HTTP/1.1\r\nHost: mcp-search.internal\r\nContent-Type: application/json\r\nContent-Length: 77\r\n\r\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\"}}";
    expect ~ "\"protocolVersion\"";
}

server {
    listen 443 ssl;
    server_name mcp-search.internal;

    location /mcp {
        proxy_pass http://mcp_search;
        proxy_set_header Connection "";  # HTTP/1.1 keepalive
        proxy_read_timeout 60s;
    }
}

If you're using Caddy (common for MCP servers on Fly.io or VPS), use an application-level health route that calls initialize internally:

// health.ts — expose /health route that verifies MCP server is ready
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

export function addHealthRoute(app: Express, mcpServer: McpServer) {
    app.get("/health", async (_req, res) => {
        try {
            // Verify tool list is populated (initialize was successful)
            const tools = await mcpServer.getTools();
            if (tools.length === 0) {
                return res.status(503).json({ status: "degraded", reason: "no tools registered" });
            }
            res.json({ status: "ok", tool_count: tools.length });
        } catch (err) {
            res.status(503).json({ status: "error", reason: String(err) });
        }
    });
}

Blue-green deployment for schema changes

MCP tool schema changes (adding tools, removing tools, changing inputSchema) are high-risk deployments. Agent frameworks typically cache the tool list from the initialize handshake for the duration of a connection. If you update the schema mid-run, the agent is using a stale tool list and may call tools with arguments the new schema rejects, or fail to discover newly added tools.

Blue-green deployment solves this by running old (blue) and new (green) versions simultaneously:

# blue-green-deploy.sh — safe schema change deployment

#!/bin/bash
set -e

SERVICE_NAME="mcp-search"
NEW_IMAGE="$1"
HEALTH_URL="https://mcp-search.internal/health"
MCP_URL="https://mcp-search.internal/mcp"

echo "=== Blue-green deployment: $SERVICE_NAME ==="

# 1. Start green instance (new version) on alternate port
docker run -d \
    --name ${SERVICE_NAME}-green \
    -p 8081:8080 \
    -e MCP_ENV=production \
    "$NEW_IMAGE"

# 2. Wait for green to be healthy
echo "Waiting for green instance health..."
for i in $(seq 1 30); do
    if curl -sf http://localhost:8081/health >/dev/null; then
        echo "Green instance healthy after ${i}s"
        break
    fi
    if [ $i -eq 30 ]; then
        echo "ERROR: Green instance failed health check after 30s"
        docker rm -f ${SERVICE_NAME}-green
        exit 1
    fi
    sleep 1
done

# 3. Verify MCP protocol handshake on green
echo "Verifying MCP initialize on green..."
INIT_RESPONSE=$(curl -sf -X POST http://localhost:8081/mcp \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","clientInfo":{"name":"deploy-check","version":"1.0"}}}')

if ! echo "$INIT_RESPONSE" | grep -q '"protocolVersion"'; then
    echo "ERROR: MCP initialize failed on green: $INIT_RESPONSE"
    docker rm -f ${SERVICE_NAME}-green
    exit 1
fi
echo "MCP initialize succeeded on green"

# 4. Shift load balancer to green (Nginx upstream weight update)
# Replace with your LB API call (AWS ALB, Nginx Plus, etc.)
echo "Shifting traffic to green..."
./update-lb-weight.sh blue=0 green=100

# 5. Wait for in-flight blue requests to drain (30s grace period)
sleep 30

# 6. Stop blue
docker rm -f ${SERVICE_NAME}-blue
docker rename ${SERVICE_NAME}-green ${SERVICE_NAME}-blue

echo "=== Deployment complete ==="

Step 3 (MCP initialize verify) is the gate that prevents deploying a schema regression — if the new version fails the protocol handshake, you know before routing any production traffic to it.

Multi-region active-active

Enterprise teams with globally distributed agent workloads run MCP servers in multiple regions to reduce latency and provide regional fault isolation. The key design decision: are regions active-active (all regions serve traffic) or active-passive (one primary, others warm standby)?

Active-active is preferred for MCP servers because MCP protocol calls are stateless at the tool level — each tools/call is independent. Route clients to their nearest region for minimum latency, with automatic failover to a healthy region on errors:

# Caddy Caddyfile — global reverse proxy with health-check routing
# (Deploy on Fly.io, which provides anycast routing by default)

{
    # Fly.io handles anycast routing — all regions serve via the same IP
    # Region selection happens at the edge based on client location
}

mcp-search.fly.dev {
    reverse_proxy {
        # Primary: same region as client (Fly.io resolves this via anycast)
        to http://mcp-search.internal:8080

        # Health check — probes the MCP health endpoint
        health_uri /health
        health_interval 10s
        health_timeout 5s

        # Failover: if local region unhealthy, Fly.io routes to next closest
        lb_policy first
        fail_duration 30s
    }
}

One consideration for active-active MCP: tool schemas must be identical across all regions, and schema changes must be deployed to all regions before traffic is shifted. A region running an old schema version while another runs a new one creates inconsistent tool lists across connections.

Change management integration

Enterprise IT environments typically require changes to production systems to go through a formal change management process — a Change Advisory Board (CAB) review, a ticket in ServiceNow or Jira, and a defined approval workflow. MCP server deployments, especially schema changes, should be treated as production changes.

# Makefile — change management gate before MCP deploy
.PHONY: deploy-production

deploy-production: check-change-ticket verify-schema-diff deploy-notify
	@echo "Production deployment complete"

check-change-ticket:
	@# Require a JIRA ticket number to be set
	@test -n "$(CHANGE_TICKET)" || (echo "ERROR: Set CHANGE_TICKET=PLAT-XXXX" && exit 1)
	@# Verify ticket is in 'Approved' state via JIRA API
	@./scripts/verify-change-ticket.sh "$(CHANGE_TICKET)"

verify-schema-diff:
	@# Generate diff of MCP tool list between current and new version
	@docker run --rm "$(NEW_IMAGE)" node -e "require('./dist').listTools().then(t => console.log(JSON.stringify(t)))" \
	    > /tmp/new-schema.json
	@curl -sf https://mcp-search.internal/mcp \
	    -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
	    | jq '.result.tools' > /tmp/current-schema.json
	@diff /tmp/current-schema.json /tmp/new-schema.json \
	    | tee /tmp/schema-diff.txt
	@# Fail if any tools were REMOVED (breaking change)
	@if grep "^<" /tmp/schema-diff.txt | grep -q '"name"'; then \
	    echo "ERROR: Schema diff shows tool removal — requires extended review"; \
	    exit 1; \
	fi

deploy-notify:
	@# Post deployment notification to ops Slack channel
	@./scripts/slack-notify.sh "#mcp-deployments" \
	    "Deploying $(NEW_IMAGE) for $(CHANGE_TICKET) — schema diff: $$(wc -l /tmp/schema-diff.txt | awk '{print $$1}') lines"

The verify-schema-diff target catches tool removals — the most breaking type of schema change. Tool additions are backward-compatible (agents that don't know about the new tool just don't call it). Tool removals are breaking (agents that cached a tools/list response with the deleted tool will fail when they try to call it).

Rollback procedures for schema regressions

Schema rollback is more complex than binary rollback because agents may have cached the new (broken) tool list. The rollback sequence must account for connection state:

1. Deploy previous image version — roll back the container to the last known-good image
2. Verify protocol handshake — confirm the previous schema is being served (use curl to hit tools/list and check expected tool names)
3. Force-close persistent connections — agents holding persistent connections to the broken version need to reconnect to pick up the restored schema. If you're using Caddy or Nginx, issue a graceful reload to terminate keepalive connections
4. Verify AliveMCP shows green — external probe confirms the rollback succeeded from outside your network
5. Notify affected teams — if schema was broken for more than 5 minutes, agent runs during that window may have failed; teams running automated pipelines need to know to re-run

Out-of-band monitoring for enterprise deployments

Enterprise MCP servers are typically deployed inside private networks, behind VPNs or corporate firewalls. This creates a monitoring blind spot: your internal health checks confirm the server is up from inside the network, but they can't detect failures that affect external clients (VPN connectivity issues, DNS resolution failures, TLS certificate expiry on the edge terminator).

AliveMCP probes MCP endpoints from outside your network — the same path an external agent client takes to reach your server. This catches failures that internal probes miss:

• TLS certificate expiry on the reverse proxy (internal health check uses HTTP to localhost, doesn't test TLS)
• VPN split-tunneling changes that block the MCP port for remote workers
• DNS propagation failures after infrastructure changes
• Network firewall rule changes that accidentally block MCP traffic on port 443

For private MCP servers (Team or Enterprise tier), AliveMCP can probe from a dedicated IP range you whitelist in your firewall — giving you external verification without opening your MCP endpoints to the public internet. The probe frequency (every 60 seconds) means network-layer failures are detected within a minute rather than waiting for a user to report that their agent run failed.

Further reading

• MCP server Kubernetes deployment — pods, services, and health checks
• MCP server zero-downtime deployment — connection draining and schema safety
• MCP server multi-region — latency routing and regional failover
• MCP server SOC 2 — change management controls and availability evidence
• MCP server SLA — uptime commitments, reporting, and breach credits
• MCP server load balancing — connection routing and failover
• AliveMCP — continuous protocol monitoring for MCP servers