Skip to main content
When you deploy a hosted server, FastMCP Gateway packages your Python MCP or FastMCP server and makes it available at a deployment URL. The compute model describes what happens when MCP clients call that URL: how FastMCP Gateway starts your server, handles independent requests, and records logs and metrics.
The compute model is separate from build behavior. For entrypoint detection, Python version selection, and dependency installation, see Build system. For the request layer in front of deployed servers, see Gateway.

​
Execution contract

FastMCP Gateway runs hosted servers as HTTP MCP servers. Your server entrypoint is started with FastMCP, bound to an internal HTTP port, and exposed through the FastMCP Gateway MCP endpoint for that deployment.

Python server

FastMCP Gateway runs the Python or TypeScript entrypoint produced by the build system.

HTTP MCP endpoint

MCP clients connect to the deployment URL, usually ending in /mcp.

Request window

Hosted server requests have a -second timeout.

Memory allocation

Hosted servers currently run with MB of memory.

Ephemeral filesystem

Local files are not durable across compute instances or redeploys.

​
Where compute fits

The compute layer is one part of the hosted server lifecycle. This separation matters when you are debugging: locate which layer a failure came from, then look at the failures typical of that layer.

​
From artifact to serving

1

A build artifact is selected

A successful build produces a deployable artifact. FastMCP Gateway serves traffic from the artifact selected by the deployment, such as the current live deployment or a preview deployment.
2

Server compute starts on demand

FastMCP Gateway starts server compute when traffic needs to be served. The first request to a fresh instance can take longer because the runtime, dependencies, and your server module need to load.
3

Your server listens for HTTP MCP traffic

FastMCP Gateway starts your FastMCP server over HTTP. MCP clients continue to call the FastMCP Gateway deployment URL; the gateway forwards supported requests to the running server.
4

Your code handles the MCP call

Tool, resource, and prompt handlers run in your server process. Code that executes at import time may run during startup, before an individual MCP request handler is called.
5

FastMCP Gateway records compute data

FastMCP Gateway captures request outcomes, latency, and server logs so you can debug deployed behavior.

​
What runs in compute

The runtime version, installed dependencies, source files, and entrypoint come from the build artifact. FastMCP Gateway does not reinstall dependencies when a request arrives. To change the runtime version, dependencies, entrypoint, or packaged source, update the repository or server settings and create a new build. The deployed server changes only after a deployment of the successful build artifact completes.

​
Environment variables

Deployment environment variables are available to the running server. Treat environment variables as configuration for startup and request handling. Changing environment variables requires a new deployment before the running server sees the new values. Avoid printing secrets to stdout or stderr; those streams become server logs.

​
Request window and long-running work

Hosted server requests time out after seconds. This limit applies to the request from the MCP client through FastMCP Gateway to your deployed server. Use request handlers for work that can complete within that window. Hosted MCP background tasks are not currently supported. For longer or retryable work, submit a job to an external worker or job service and return a job ID. Store progress and results outside the hosted process so later calls can retrieve them. Work started inside a hosted process has no guarantee of continuing after the request returns.

​
Choose the right execution path

FastMCP Gateway does not support long-lived GET /mcp streams for hosted servers. Use the standard HTTP request flow for MCP calls, and move long-running work out of the request path.

​
Sessions and local state

Hosted servers handle each MCP request independently. As described in the gateway session contract, legacy initialization does not create a persistent hosted session. A later call can run on a different instance with different memory and local files. Use durable external storage for application state needed across calls. An MCP session ID or a value stored in server memory cannot guarantee that continuity.

​
Instances and reuse

FastMCP Gateway starts server compute as needed to serve traffic. A request may be handled by a fresh server process or by one that is already running. You can cache reusable clients in memory when that is safe, but in-memory state is opportunistic. Treat it as a performance optimization, not a source of truth.

​
Filesystem

The deployed artifact contains your source code and installed dependencies. You can use temporary local files while handling a request, but the local filesystem is ephemeral and should not be used for durable application state. Do not rely on files written during one request being available to another request. Do not rely on files written before a redeploy being available after the redeploy.

​
Cold starts and startup work

FastMCP Gateway can start server compute on demand. The first request to a new instance may take longer than later requests because the runtime, dependencies, and your server module need to load. Keep import-time work small:
  • avoid network calls during module import
  • lazy-load large clients or models when possible
  • move expensive setup into request handlers or an external worker
  • cache reusable clients in module-level variables when that is safe

​
Defaults and limits

For a broader list of product limits, see Limits.

​
Common compute failures

The handler took longer than seconds, or startup work consumed too much of the request window. Move long work out of the request path, reduce import-time work, or split the operation into smaller calls.
A fresh compute instance may need to start the runtime, import dependencies, and load your server module. Keep module imports lightweight and defer expensive setup until it is needed.
Local files are temporary. Use local files only as scratch space, and store durable state outside the local filesystem.
Reduce per-request memory use, avoid loading large objects at import time, and stream or page large results when possible.
Build inputs take effect after a new successful build and deployment. Environment variables take effect after a redeployment. Check which deployment is live.
Stdout and stderr are captured as server logs. Avoid printing secrets, tokens, credentials, or full environment dumps.

Gateway

Understand the request layer in front of deployed servers.

Build system

Learn how FastMCP Gateway creates the artifact that compute runs.

Deployments

Learn how successful build artifacts are deployed and rolled back.

Environment variables

Configure values available to builds and deployed servers.

Limits

Review compute and product limits.