Managed MCP Servers

A managed MCP server is one that runs in your own infrastructure and is organized as named instances — separate deployments of the same server for different users, teams, customers, or environments — that MCP Manager connects to securely and governs as one server. An instance can be registered where it is already deployed and reachable at a URL, or created from scratch: take a server that would normally be launched with a local command — for example an npx or uvx package that speaks over stdio — and run a command MCP Manager generates to start it as a containerized server on your own hardware. Either way, MCP Manager reaches every instance through the gateway, and each user connection exchanges information with exactly one instance of the server.

​

When to choose Managed over Remote

The deciding question is how many instances of the server you need — not who owns the hardware it runs on. If your MCP server is running at a URL — a SaaS vendor’s endpoint or one you self-host — and you only ever need one copy of it, add it as a Remote server. MCP Manager simply connects to it; there is nothing else to set up. Choose Managed when either of these is true:

• You need more than one instance of the same server. Managed lets you run separate, named instances per user, team, project, customer, or environment, and assign each to the right gateways and groups — something a single Remote entry can’t do. The instances can each already be running at their own URL; being reachable at a URL doesn’t make a multi-instance server a Remote server.
• Get a ready-to-run command for a command-launched server. When a server ships as a stdio command (an npx/uvx package or a Docker image) rather than a hosted URL, MCP Manager generates a command you run in your own environment that launches it as a containerized HTTP server — so you don’t have to work out how to wrap and expose it yourself. You still provide the hardware and run the command.

In short: Remote is “point MCP Manager at the one URL that already exists”; Managed is “the same server as several governed instances — registered from the URLs where they already run, or launched from a command MCP Manager generates.”

​

Separate staging and production with per-environment instances

A common multi-instance case is environment separation: the same self-hosted MCP server deployed for staging, sandbox, and production, each at its own URL and connected to a different backend. Registering each environment as a named instance of one managed server keeps the environments unmistakably distinct — every instance carries its own name, connection details, and identities, and a user connecting through a gateway selects the instance (and their identity for it) explicitly, rather than guessing which of several look-alike URLs points at production data. How the instances map to gateways is a topology choice:

• One gateway serving several environments — whether to different groups of people or side by side to the same people — is exactly what per-environment managed instances are built for.
• A separate gateway per environment, where each gateway only ever carries that environment’s deployment, can instead use one Remote server per gateway — the simpler flow when instances never share a gateway.

​

Managed-Dedicated and Managed-Shared

Managed deployments come in two patterns, distinguished by whether each user gets their own container instance or everyone shares one.

​

Managed-Dedicated

In a Managed-Dedicated deployment, each user or agent gets their own container instance. Choose this when a server can’t safely be shared — for example, browser automation with Playwright or Puppeteer, where many developers driving a single browser session at once would collide. Each developer (or agent) gets an isolated, reproducible environment. The trade-off is higher resource use (one instance per user) and more orchestration to create, update, and remove instances.

​

Managed-Shared

In a Managed-Shared deployment, a single container instance serves many users. Choose this when a resource is better centralized — for example, a Memory MCP holding shared coding standards, where a few users have write access and most read. Sharing lowers administrative overhead and keeps everyone on one version, but permission and security enforcement is more complex, and performance can lag if many clients crowd one instance.

​

What you need to set up a managed server

To create and connect a managed server, you need:

• SSH access to your hosting environment — by SSH password or SSH key — used during setup to launch and verify the server in your environment.
• The ability to run new containers in that environment (Docker must be available).

MCP Manager handles authentication between itself and your managed server automatically. Each managed server is assigned a shared secret that only MCP Manager and the server know, so requests are authenticated without any extra configuration from you.

​

The setup experience

When you add an instance to a managed server, MCP Manager first asks which of two situations you’re in:

• My server instance is already deployed. For an instance already running at a URL in your infrastructure, registration follows the same URL-and-authentication flow as a Remote server — the difference is that the result becomes a named instance of this managed server rather than a standalone entry, so it can sit alongside its sibling instances and be assigned independently.
• Help me set up a new MCP server instance. For a server that isn’t running yet, an in-product wizard walks you through the entire setup, shown below.

​

Lock your server to MCP Manager (defense in depth)

Because a managed server runs in your infrastructure, you can ensure it is reachable only through MCP Manager — never directly from the public internet. MCP Manager connects to your servers from a single static IP address, which you can find at Security → IP addresses. Restrict your server’s inbound firewall to accept connections only from that IP. Combined with the per-server shared secret, this gives you defense in depth: the server isn’t exposed to the open internet, and even a request that reached its port would still need the secret. This same allowlisting applies to a self-hosted Remote server you want to keep private.

​

How requests reach a managed server

The container you launch includes an authentication layer that validates each request from MCP Manager — using the per-server shared secret — before forwarding it to the MCP server process. This means your server is protected even if the container’s port is reachable from other sources on your network.

​

Identities for managed servers

Like every server type, a managed server uses identities to control who can access it and with what credentials. An identity is Private by default, or Global to share it across your organization; administrators can require per-user identities or share a single identity across a gateway. See the identities section of the overview for the full model.

​

Pros and cons

• Pros: runs the same server as separate governed instances per user, group, customer, or environment; keeps full gateway governance over servers on your own hardware; MCP Manager generates a ready-to-run command for command-based servers; reproducible, standardized environments via containers.
• Cons: more to set up and operate than pointing at an existing URL; you supply and maintain the hardware; dedicated deployments use more resources and need orchestration; shared deployments make permissions and contention harder to manage.

​

Further reading

​

External sources