Skip to main content
A managed tunnel gives Gumloop a secure path to MCP servers that only exist inside your network — on a VPC, a corporate network, or a developer machine. You run a lightweight connector next to your servers, it dials out to Gumloop, and each server becomes usable in Gumloop like any other Proxied MCP. No inbound firewall rules, no public IP, and no changes to the MCP servers themselves.
Managed Tunnels page under Settings → Organization showing the tunnel table and Add tunnel button

Where to find it

Go to Settings → Organization → Managed Tunnels at gumloop.com/settings/organization/managed-tunnels.
Managed Tunnels is an Enterprise feature, and creating, editing, or deleting a tunnel requires the same organization-admin permission as Proxied MCPs. Contact your organization admin if you don’t see it under Settings → Organization.

How it works

  1. You create a tunnel in Gumloop. Gumloop provisions it for you and assigns it a domain — you don’t need a Cloudflare account of your own.
  2. You run the Cloudflare connector (cloudflared) on a machine that can reach your MCP servers, using the tunnel’s connector token. The connector makes an outbound connection only.
  3. You attach each MCP server to the tunnel by giving it a name and the local address it runs on (for example http://localhost:8000/mcp).
  4. Gumloop publishes each attached server on its own subdomain under gumlooptunnels.com and routes requests through the tunnel to that local address. Every hostname is protected by its own access credential that Gumloop manages, so only Gumloop can call it.

When to use a tunnel

Create a tunnel

1

Add the tunnel

On the Managed Tunnels page, click Add tunnel and give it a name that describes the network it reaches into — for example, “Prod network”. A domain is assigned automatically once the tunnel is created.
Create tunnel dialog with a Name field
Each organization can have one managed tunnel. You can attach as many MCP servers to it as you need.
2

Start the connector

Gumloop shows the connection steps as soon as the tunnel is created, including the exact command to run with the tunnel’s token.
Tunnel created dialog with three steps: install cloudflared, start the connector, attach your MCP servers
  1. Install cloudflared on a machine that can reach your MCP servers — follow Cloudflare’s install guide for your OS.
  2. Run the connector with your tunnel token:
  3. Keep it running. The tunnel stays online only while the connector is running, so run it as a service on a long-lived host rather than an ad-hoc terminal.
You can reopen these instructions and reveal or copy the token any time from the tunnel’s Settings tab.
3

Attach your MCP servers

Open the tunnel and, on the Overview tab, click Attach server.
Tunnel detail page Overview tab with no MCP servers attached yet
Give the server a name and the local address the connector should forward to — the address the server listens on from the connector machine’s point of view, including the scheme and the MCP path.
Attach MCP server dialog with Name and Local address fields
Each attached server gets its own subdomain and MCP URL, listed on the Overview tab next to the local address it points at.
Tunnel Overview tab listing an attached MCP server with its MCP URL and local address
4

Load its tools

An attached server appears in Proxied MCPs, with a Tunneled via tunnel name link back to the tunnel and the local address shown on its Overview tab.
Proxied MCP detail page for a tunneled server showing Tunneled via Prod network, the MCP Server URL, and the local address
Once the connector is running, click Fetch New Tools to discover the server’s tools. From there it behaves like any other proxied server: per-role tool access control, activity and usage stats, and availability to agents and flows.

Tunnel status

The status badge on the tunnel list and detail page reflects the live state of your connector:

Manage a tunnel

The tunnel’s Settings tab is where you rename it, retrieve the connector token, and delete it.
Tunnel Settings tab showing Tunnel Name, Connector token, Delete Tunnel, and the connect instructions
  • Tunnel Name — the display name; renaming doesn’t affect the domain or any attached server.
  • Connector token — masked by default. Reveal or copy it when you need to start the connector on a new machine. Treat it like a password: anyone with it can connect a connector to your tunnel.
  • Delete Tunnel — permanently removes the tunnel and its assigned domain.
You must delete the MCP servers attached to a tunnel before you can delete the tunnel itself; Gumloop blocks the deletion and lists what’s still attached. After deleting, stop the cloudflared process on your machine — it can no longer connect.

Security

  • Outbound only. The connector opens a connection from your network to the tunnel. You never open an inbound port or expose your MCP server to the internet.
  • Per-server access control. Each attached server is published on its own hostname behind its own access credential, which Gumloop provisions and stores for you. Requests that don’t carry it are rejected at the edge, before they ever reach your network.
  • Your local addresses stay internal. The local address is only used by the connector inside your network; it’s never the address MCP clients talk to.
  • Admin-gated. Only organization admins can create tunnels, read the connector token, attach servers, or delete a tunnel.

Troubleshooting

The connector isn’t connected. Check that cloudflared is running on the machine, that it was started with the current token from the tunnel’s Settings tab, and that the machine has outbound internet access. The status updates when you reload the page.
Its tools haven’t been discovered yet. Make sure the connector is running and the local address is correct, then click Fetch New Tools on the server’s detail page.
A healthy tunnel means the connector is reachable — not that your MCP server is. Verify that the local address you attached responds from the connector machine (for example, curl it there), and check the connector’s logs for connection errors to that origin.
Managing tunnels requires the organization permission for external MCP servers. Ask an organization admin to create the tunnel and attach servers, or to grant you the permission.

FAQ

No. Gumloop provisions and manages the tunnel. You only install cloudflared and run it with the token Gumloop gives you.
On any always-on machine that can reach your MCP servers — a VM in the same VPC, a container in your cluster, or a bastion host. Run it as a service so it restarts with the machine.
Yes. Attach as many as you like; each gets its own subdomain and its own MCP URL, and each shows up separately under Proxied MCPs.
Yes. Running the same command on a second machine adds another connection to the tunnel, which is a common way to avoid a single point of failure.
Delete the server from its Proxied MCPs settings. That removes its tunnel route and its subdomain; the tunnel and its other servers are unaffected.