← Back to Forum
25
Official Announcements
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/mcpin 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)
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.
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.
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.
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.
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.
Same, I dont want to rebuild a working setup just to put one endpoint online. The bit I liked was getting the
/mcppath on the public URL automatically, that's one less little thing to mess up when you're trying to get a client connected fast.Please log in to post a comment.