Global edge architecture

When you publish a hosted MCP server, MCP Stack deploys your runtime across a global edge stack built on Azure Front Door and Azure Container Apps, with a warm regional edge-routing layer in front of scale-to-zero runtimes.

This guide explains the architecture in enough detail that you can reason about latency, cold starts, health, and scaling.

Two layers of "edge"#

MCP Stack uses two complementary edge layers:

Front Door gets your traffic onto MCP Stack's network at the nearest healthy edge location. Regional compute is where tool calls actually execute. Both layers matter: Front Door reduces connection latency and centralizes TLS; regional edge routers and runtimes keep execution close to Azure regions where your server is deployed.

MCP clients enter through Azure Front Door, reach a fixed regional edge-router origin, and the edge router forwards to your hosted runtime in that region.

Production request path#

Every hosted MCP tool call follows the same data path in production:

MCP client
  -> Azure Front Door (nearest healthy edge POP)
  -> regional edge router (fixed platform origin)
  -> hosted MCP runtime Container App
  -> your upstream API

Important design choices in that path:

• One Front Door route, not one origin per customer. Hosted MCP traffic uses a shared wildcard route (*.mcp.<domain>). Front Door forwards to a small set of regional edge-router origins. The edge router resolves hostname to the correct server.
• Edge routers stay warm; runtimes scale to zero. Regional edge routers run with minReplicas = 1. Your hosted runtime defaults to minReplicas = 0 so idle servers do not consume compute.
• Cold-start masking at the edge router. When a runtime has scaled in, the edge router probes internal /health for up to 90 seconds, then forwards your original MCP request exactly once. Non-idempotent tool calls are not retried by the edge router.
• Control plane stays separate. The MCP Stack API builds images, publishes runtimes, records usage, and enforces quotas. Edge routers and runtimes execute traffic; they do not mutate infrastructure.

If you use a custom MCP domain, customer traffic still follows the same path after TLS terminates at Front Door. The hostname changes; the routing model does not.

Production edge regions#

Hosted MCP servers deploy to every enabled production edge region. Region placement is platform infrastructure, not a per-server setting you pick in the dashboard.

When MCP Stack adds a production region, the rollout is platform-managed. New publishes automatically materialize runtime targets in the new region; you do not republish per server.

Compute scaling model#

Each hosted server becomes one Container App per enabled region. Within a region, Azure Container Apps handles replica scaling.

Edge routers stay warm while runtimes scale from zero to ten replicas per region based on HTTP concurrency.

Default runtime limits (self-serve)#

Under sustained load, MCP Stack adds replicas until the concurrency rule is satisfied or the region hits maxReplicas. When traffic drops, replicas scale in after the cooldown window.

Edge router scaling#

Regional edge routers use a smaller footprint (0.25 vCPU, 0.5 GiB) with minReplicas = 1 and maxReplicas = 2. Edge routers are routing and policy-enforcement layers, not tool executors. Keeping them warm avoids adding edge-router cold starts on top of runtime cold starts.

Platform scaling#

Hosted runtimes run in shared regional environments, and MCP Stack expands platform capacity automatically as the number of hosted servers grows. This is platform infrastructure: you do not manage capacity, placement, or regions, and your server keeps a stable assignment for its lifetime.

Health checks and routing decisions#

MCP Stack uses layered health signals rather than a single boolean "up" flag.

Azure Front Door origin probes#

Front Door origin groups probe backend health every 30 seconds over HTTPS. Production edge-router origins use /health. Load balancing requires 3 of 4 successful samples before an origin is considered healthy.

Front Door also applies a profile-wide 150-second origin response timeout. That timeout is intentional: it gives the edge router enough time to wait for a scale-from-zero runtime without Front Door cutting the client connection early.

Container Apps probes#

Hosted runtimes and edge routers expose /health with startup, readiness, and liveness probes. Generated runtimes emit a structured boot-ready log event at startup so cold-start duration is measurable in publish logs.

Edge router readiness coalescing#

When multiple requests hit a scaled-in runtime, the edge router coalesces readiness waits per deployment target inside each edge-router instance and caches success briefly (default 60 seconds). That prevents a thundering herd of cold-start probes for the same server.

What you see in the dashboard#

On the server Hosting tab, Global edge health summarizes regional target status: how many regions are healthy versus deployed. Use that view after publish, spec changes, or upstream outages.

For deeper operational signals, see Monitor usage and operations.

Verify edge health from the CLI#

Use smoke checks after publish or configuration changes:

# Confirm tools/list succeeds against the hosted MCP URL
mcpstack smoke tools-list support-api --json
 
# Inspect server health and publish state
mcpstack servers get support-api --json
mcpstack servers checks support-api --json

Example smoke output shape:

Smoke test: tools/list
Server: support-api
Transport: streamable-http
Status: passed
Tools discovered: 14

If smoke passes but agents fail, compare Gateway logs and runtime logs for the same timestamp before assuming an edge outage.

What "global edge" does and does not promise#

MCP Stack provides global routing and multi-region deployment so you can ship MCP servers without operating your own edge stack. Be precise about what that means:

You get

• Managed TLS and HTTPS redirect at Front Door
• Multi-region runtime deployment on every publish
• Warm regional edge routers in front of scale-to-zero runtimes
• Cold-start masking with bounded edge-router wait time
• Health probes at the edge, edge-router, and runtime layers
• Publish logs, regional health, and smoke tests in the dashboard

You should plan for

• Cold starts after idle periods. Scale-to-zero saves cost but the first request after idle may wait while a runtime boots. The edge router masks much of this, but it is not a zero-latency guarantee.
• Regional execution, not automatic cross-region failover for a single hostname. Your server runs in all enabled regions; Front Door selects healthy edge-router origins. MCP Stack does not publish a separate per-region URL for you to manually failover between.
• Platform-wide edge maintenance. Azure Front Door and Container Apps maintenance can affect routing or individual regions. Use dashboard health and smoke tests during incidents.

MCP Stack does not publish a numeric uptime SLA in this documentation. Treat smoke checks, regional health, and logs as your operational source of truth.

How this fits the product model#

Host runs your generated MCP runtime. Gateway (optional) adds OAuth and public client discovery. The global edge stack sits under Host:

OpenAPI -> generated MCP runtime -> Host publish -> global edge route -> MCP clients/agents

For the full product layering diagram, see MCP Stack product model. For publish workflow steps, start with Create a hosted server.

Quick reference#

Related guides#

• Create a hosted server — publish workflow and hosted URL shape
• Set up a custom MCP domain — customer-owned hostnames on the same edge path
• Monitor usage and operations — logs, smoke tests, and incident order