Managed MCP Servers

What managed MCP servers are — MCP servers you launch in your own infrastructure using a command MCP Manager generates, so MCP Manager can connect to them securely — when to choose Managed over Remote, the Managed-Dedicated and Managed-Shared patterns, the guided setup, locking the server to MCP Manager’s static IP, and the per-server shared secret.

A managed MCP server is one you run in your own infrastructure using a command MCP Manager generates for you, so MCP Manager can connect to it securely. You 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 MCP Manager’s generated command to start it as a containerized server on your own hardware. MCP Manager then reaches it through the gateway. It is the “easy button” for connecting a server that isn’t already available at a URL, and it lets you run different instances for different users or groups.

MCP Manager is a gateway, not a host. It never runs your servers on its own hardware. A managed server runs on infrastructure you provide — MCP Manager only generates a ready-to-run command that launches the container in your environment, then secures and governs the connection to it. You bring the hardware. We recommend hosting your custom-built MCP servers in your own infrastructure and managing the secure connection through MCP Manager.

Creating managed servers is gated by capabilities: Deploy new server instances and Create and configure managed and workstation servers. If you don’t see the option to add a managed server, your role doesn’t have the relevant capability — ask a workspace administrator to grant it. See the capabilities reference.

When to choose Managed over Remote

If your MCP server is already running at a URL — whether it’s a SaaS vendor’s endpoint or one you self-host and expose on the web — add it as a Remote server. MCP Manager simply connects to it; there is nothing else to set up.

Choose Managed when you want MCP Manager to do more than connect to an existing URL:

• 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.
• Run different instances for different users or groups. You can stand up separate instances per user, team, project, or customer — something a single shared URL can’t do. This is the main reason to pick Managed even for a server you could otherwise host yourself.

In short: Remote is “point MCP Manager at a URL that already exists”; Managed is “MCP Manager gives you a command to launch and run the server in your own infrastructure, then connects to it securely.”

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

MCP Manager provides an in-product wizard that walks you through the entire setup.

1. Configure your server

   Provide the server details — the instance name, the MCP server image or command, and any required environment variables or configuration.

2. Connect to your environment

   Provide the SSH connection details for your hosting environment, using either an SSH password or an SSH key.

3. Run the generated command

   The wizard generates a single terminal command tailored to your configuration. Copy it and run it in your hosting environment. Running the command pulls the image, launches the server as a container with the correct networking and authentication, and starts it.

4. Test the connection

   Use the built-in test to verify that MCP Manager can reach your managed server and discover its available tools.

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.

Some managed servers need configuration beyond what the wizard covers — for example, a server that authenticates to a database with a credentials file, or that needs access to other secure resources. You may need to configure those separately; MCP Manager can help facilitate that process.

Pros and cons

• Pros: MCP Manager generates a ready-to-run command that launches a command-based server in infrastructure you provide; keeps full gateway governance over a server running on your own hardware; can run separate instances per user or group; 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

Workstation MCP Servers

Govern a local-machine server through an encrypted tunnel.

Remote MCP Servers

For servers already running at a URL — SaaS or self-hosted.

External sources

Docker documentation

Reference for the container runtime managed servers depend on.