MCP Servers on the Edge: Cloudflare Workers, Bun, Deno, Netlify Functions, and Azure Functions

Cloudflare Workers: V8 isolates and the distributed monitoring problem

Cloudflare Workers does not run Node.js. Your Workers MCP server runs in a V8 isolate — a lightweight JavaScript context with no file system, no native Node.js modules, and no access to the operating system. The first decision this forces is transport: use StreamableHTTPServerTransport instead of SSEServerTransport. The SSE transport assumes a long-lived process that can hold an open HTTP connection for the lifetime of a session; a Workers request completes in at most 30 seconds of CPU time, making persistent SSE connections impossible.

The second constraint is state. Each Worker invocation is stateless — there is no in-process sessions Map that survives between requests. If your MCP server needs to preserve context across a multi-turn tool sequence (a common pattern when an LLM calls start_job and then get_job_result with the returned ID), you need Durable Objects. A MCPSession Durable Object receives all requests that share the same mcp-session-id header, giving you isolated per-session SQLite-backed storage. Durable Objects idle-evict after 30 days; a re-activated Durable Object after a long idle period counts as a fresh instantiation and incurs a first-call latency spike that looks to AliveMCP like a slow response, not an error.

The third constraint — and the most surprising from a monitoring perspective — is distribution. When you deploy to Cloudflare Workers, your server runs at 300+ edge locations simultaneously. A traditional uptime probe from a single IP address tests only the nearest edge node. If that node is healthy but 40% of your users are served by a different edge colocation that is running a stale deploy or experiencing a regional issue, your single-IP probe shows green while those users see failures. External protocol monitoring from AliveMCP sends the full initialize handshake and verifies the protocolVersion in the response — catching cases where a new deploy is serving the correct protocol on one edge and a broken bundle on another.

Environment variables on Workers are environment bindings: secrets set with wrangler secret put and non-secret configuration in wrangler.toml [vars]. Both are accessed as env.BINDING_NAME in the Worker handler, not process.env. An MCP server that references process.env.API_KEY directly will compile without error and fail at runtime with undefined — but only when a tool that uses that key is called. The initialize and tools/list paths will appear healthy. Only an external probe that exercises an actual tool call catches this failure class.

Bun: native TypeScript and restart-loop visibility

Bun is the simplest runtime transition from Node.js for MCP server development. The Bun MCP server setup eliminates the TypeScript compilation step — you run .ts files directly with bun run server.ts, no tsconfig.json required for basic usage, no ts-node or tsx wrapper needed. The @modelcontextprotocol/sdk package installs and works without modification because Bun's Node.js compatibility layer covers the standard module surface the SDK uses.

The main practical differences from Node.js are tooling, not protocol: bun install instead of npm install (roughly 3× faster), bun:test instead of Vitest or Jest (Jest-compatible API, native TS parsing makes it faster), bun --watch instead of nodemon, and Bun.Database as a built-in SQLite binding that replaces better-sqlite3 without a native module compilation step. The API surface is the same: prepare().all(), prepare().run(), WAL mode configuration.

Bun's startup time advantage — 100–300ms faster than the equivalent Node.js process — has a monitoring consequence. If you configure AliveMCP with a cold-start alert threshold calibrated for Node.js (say, 2 seconds), a restarted Bun server will clear that threshold easily and look healthy even under rapid restart loops. The signal to watch is not a single slow probe response but the pattern: in AliveMCP's 90-day uptime graph, a process restart loop shows as a sequence of brief downtimes separated by short recovery windows. A single cold start looks like a momentary blip; a restart loop looks like a sawtooth. Calibrate your Bun server's alert threshold lower than you would for Node.js, so each restart is visible as a distinct event rather than absorbed into the noise floor.

One compatibility note for Bun production deployments: N-API native addons are not supported. The most common MCP server packages affected are bcrypt (replace with bcryptjs or Bun's native crypto) and better-sqlite3 (replace with Bun.Database). Both replacements are drop-in at the API level. If your existing Node.js MCP server uses any package with a .node binding, audit that before migrating.

Deno: the permission model as a monitoring surface

Deno's MCP server implementation uses the same @modelcontextprotocol/sdk package via npm: imports, the same StreamableHTTPServerTransport, and Deno's built-in Deno.serve() instead of Express. What distinguishes Deno from every other runtime in this list is its permission model: Deno requires explicit flags for every category of resource access.

The critical monitoring implication: --allow-net must include the address the server listens on. If you start Deno with --allow-net=api.example.com for outbound API access but forget to include 0.0.0.0:3000, the server will refuse to bind its listening address at startup — it fails before MCP initialization can begin. That failure is easy to catch in development. The subtler variant: if your Deno MCP server's tool handlers call an external API whose hostname is not in the --allow-net scope, the initialize handshake succeeds, tools/list succeeds, but every tool call that reaches the blocked API throws a PermissionDenied error. AliveMCP's protocol probe catches this because it exercises the full initialize path — and a periodic probe that calls an actual tool will catch the permission-scope gap that the transport-level check misses.

For production deployments requiring global distribution, Deno Deploy runs your Deno server at 35+ edge regions with Deno KV for persistent state. Deno KV is globally replicated and eventually consistent; for per-session MCP state under concurrent writes, use kv.atomic() compare-and-swap to avoid stale-read overwrites. The Deno Deploy monitoring gap mirrors the Cloudflare Workers challenge: a server running at 35 edge regions is not fully tested by a single-IP probe. AliveMCP tests from an external vantage point, verifying that the MCP protocol handshake completes correctly — not just that an HTTP 200 is returned from a Cloudflare DNS-proxied endpoint.

Netlify Functions: the 10-second wall and the cold-start warming side effect

Netlify Functions imposes the most rigid execution constraint of any runtime in this comparison: a hard timeout wall that kills the function invocation at 10 seconds by default (26 seconds on the Pro plan). There is no graceful termination, no partial response — the connection closes with a 502. For an MCP server on Netlify Functions, this means that any tool handler that might take more than 8 seconds (leaving a 2-second buffer for function overhead and MCP framing) requires the async dispatch pattern.

The async dispatch pattern splits slow work across two tool calls: start_report stores a job record in an external datastore and triggers a background function (suffixed -background or typed as BackgroundHandler), then returns a jobId. get_report polls that datastore for the result. The LLM loop calls start_report, waits a turn, calls get_report. Background functions run for up to 15 minutes, placing virtually all work within reach of this pattern.

Netlify Functions are stateless per invocation — each request to your MCP server creates a new function instance with no in-process state from previous requests. Session state must live in an external store. This makes the initialize handshake stateless too: your handler creates a fresh McpServer and transport each time, then tears them down when the invocation completes. This is different from the Node.js model where the server process is shared across sessions.

Cold starts on Netlify Functions range from 200ms to 800ms after an idle period. For an MCP server being polled by an LLM agent in production, this latency appears as the first tool call in a session being noticeably slower than subsequent calls (which hit a warm instance). AliveMCP's 60-second polling interval has a side effect that is worth knowing: it keeps your function warm during the hours when AliveMCP is probing it. If AliveMCP is configured on your Netlify MCP endpoint and probing at 60-second intervals, your function instances will not idle-evict during business hours when monitoring is active. This is not a substitute for a proper warming strategy, but it is a practical benefit of external monitoring on serverless endpoints.

The most dangerous silent failure on Netlify Functions: environment variable misconfiguration. Because Netlify Functions only accepts environment variables set in the Netlify UI (never in netlify.toml), and because those variables are scoped per deploy context, it is possible for a function to deploy successfully — initialize succeeds, tools/list succeeds — while every tool that accesses process.env.DATABASE_URL fails with an undefined connection string. The only way to catch this before a user does is a post-deploy verification step that calls an actual tool, not just checks the MCP transport. AliveMCP catches this by periodically exercising the full protocol path, not just the initialize handshake.

Azure Functions: plan selection, Durable Functions, and Key Vault rotation

Azure Functions MCP servers use the Node.js v4 programming model, where HTTP triggers are registered with app.http(). Each invocation is stateless — the handler creates a new McpServer instance and tears it down per request, the same pattern as Netlify Functions. The most consequential decision is plan selection:

For MCP servers with interactive tool calls (sub-second expected latency), a 5-second cold start on Consumption Plan is unusable. AliveMCP's 60-second probe partially mitigates this — active monitoring keeps an instance warm — but it is not a substitute for Premium Plan if your SLA requires consistent sub-100ms response times. Defer expensive initialization (database connection pools, SDK clients) to the first tool call, not the initialize handler, so the probe's initialize call returns quickly even on a cold start.

For MCP tools that need to run longer than 10 minutes on Consumption Plan, Durable Functions is the correct pattern. Orchestration is expressed as generator functions using yield context.df.callActivity(), where each yield is a checkpoint. If the function host restarts mid-workflow, Durable Functions replays the orchestrator from the last checkpoint rather than restarting from scratch. This maps naturally to the async dispatch pattern: a start_report tool calls context.df.startNew() to launch an orchestration and returns the instance ID; a check_report tool calls client.getStatus(instanceId) to poll for completion. The LLM loop handles the polling.

The Azure-specific failure mode that external monitoring uniquely catches: Key Vault reference resolution failure. Azure Functions can reference secrets as App Settings with the syntax @Microsoft.KeyVault(SecretUri=...), which the Function runtime resolves to the actual secret value at startup using Managed Identity. If the Key Vault access policy is revoked, the Managed Identity is removed, or the secret is deleted, the Function App fails to start — and all tool calls return 500 errors. This failure is invisible to Azure's own function health endpoints because the function never becomes healthy enough to respond. AliveMCP detects it as a sustained 500 spike on a previously healthy endpoint — the transition from green to repeated 500s is the alert signal, even if each individual 500 looks like a tool-call failure.

Azure Application Insights and AliveMCP monitor different things and are genuinely complementary, not redundant:

The shared monitoring gap

Five runtimes, five constraint profiles, one shared blind spot: every runtime's internal health-check mechanism — Cloudflare Workers health endpoints, Bun's process manager, Deno's supervisor, Netlify's function invocation logs, Azure's function health probe — operates from inside the runtime's own infrastructure. All five fail to catch failures that occur before a request reaches the server or inside a tool handler but not the transport handler.

The failure classes that fall into the blind spot, mapped by runtime:

The common structure of every row above: the transport path (initialize, tools/list) appears healthy; the failure lives in the path between the runtime's infrastructure boundary and the actual tool execution. Internal checks that probe the transport layer are blind to this failure class by definition — they only verify the path they can reach from inside the runtime.

An external protocol probe from AliveMCP sends the full MCP JSON-RPC sequence from outside each runtime's own infrastructure — the same path an LLM client takes. It is the only monitoring approach that catches all six failure rows above, because it observes the server from the same position as the client that will be affected.

Choosing a runtime

The choice between these five runtimes is not primarily a monitoring decision — it is a hosting, tooling, and constraint decision. The monitoring strategy that follows each choice is:

• Cloudflare Workers: External protocol probe is mandatory. Internal checks are architecturally impossible across 300+ edge nodes. AliveMCP is the primary uptime signal.
• Bun: Same monitoring as a Node.js process. Configure alert thresholds 100–300ms lower than Node.js equivalents to make restart events visible. Watch the 90-day uptime graph for sawtooth patterns indicating loop crashes.
• Deno: Add a post-deploy verification step that calls a real tool (not just initialize) to catch permission-scope errors before users do. On Deno Deploy, external probing is mandatory for the same reason as Workers.
• Netlify Functions: External probe exercises post-deploy tool call verification. AliveMCP's 60-second probing interval keeps functions warm during monitored hours as a practical side effect.
• Azure Functions: Use AliveMCP for protocol-level health and TLS/VNet/Key Vault failure detection; use Application Insights for per-function execution metrics and dependency tracing. They are complementary, not substitutes.

FAQ