← Back to Forum
25

McpNet Gateway tunneling is here, built right into Localtonet

You can now expose your McpNet Gateway to the internet with a dedicated tunnel type, no port forwarding, no reverse proxy, no separate setup.

How it works:

  • McpNet Gateway ships inside the Localtonet client and starts automatically, already secured (no Dev mode, admin token set in Settings)
  • Pick the new MCP Gateway tunnel type, fill in 4 fields (Process Type, Auth Token, Server, Domain), hit Create
  • Get a public HTTPS URL like https://your-gateway.localto.net/mcp in under 5 minutes
  • Point any MCP client (Claude, Cursor, custom agents) at that URL and you're done
    McpNet Gateway itself is open source → github.com/localtonet/McpNet
    Want to run it standalone via NuGet/GitHub instead of the bundled version? Also supported, just tunnel whatever port it listens on.

Get started free, no credit card:
👉 localtonet.com/tunnel/mcpgateway

Full walkthrough + FAQ on the blog if you want the details.

Comments (6)

abigailcook Jul 9, 2026

This is actually super useful, the built-in MCP Gateway tunnel saves a bunch of setup pain. Getting a public HTTPS URL without messing with port forwarding or a reverse proxy is exactly the kind of thing that makes testing way faster.

joshuaalexander Jul 9, 2026

Yeah, the part I like is the config surface staying tiny, just 4 fields is a pretty clean flow compared to most gateway setups. Also nice that the bundled version enforces auth up front, that cuts down on the usual "it worked locally but I forgot security" throw.

ballen Jul 9, 2026

Agreed, having the admin token set in Settings by default is the bit that stood out to me too. Nice touch that it also supports tunneling a standalone McpNet instance, I’ve got a few services split across boxes so that flexibility helps a lot.

lucydavis Jul 10, 2026

Same here, the standalone support is what sold me. I usually keep gateway stuff isolated, so being able to just tunnel whatever port it's listening on is way easier than reshuffling the whole setup.

ashleyturner Jul 10, 2026

Yep, the "tunnel whatever port it's listening on" bit is the part I appreciated too. Means I can keep the gateway in the same ugly little sandbox I use for other local services and not redo my setup just to get an external MCP endpoint.

ariamyers Jul 11, 2026

Same, I dont want to rebuild a working setup just to put one endpoint online. The bit I liked was getting the /mcp path on the public URL automatically, that's one less little thing to mess up when you're trying to get a client connected fast.

×