Compare public tunnels, private mesh access, and self-hosted relays by how they actually connect users
An ngrok alternative should match your protocol, exposure model, security requirements, and operational capacity. A public HTTPS URL, a directly reachable TCP port, a UDP relay, a client-assisted access path, and a private mesh are not interchangeable. This guide establishes an ngrok baseline, compares twelve alternatives without declaring a universal winner, and provides a repeatable workflow for safely testing a shortlist.
📋 What's in this guide
Why the ngrok alternatives landscape needs careful comparison
Ngrok helped popularize a straightforward development workflow: run an agent beside a local application, establish an outbound connection to a hosted edge, and receive an internet-reachable endpoint. That model solves a common networking problem because a service listening on localhost or a private LAN address cannot normally accept unsolicited connections from the public internet.
Many products can solve some version of that problem, but they do not all create the same kind of connection. Some publish an HTTPS application for ordinary browser visitors. Some expose a raw TCP or UDP port. Others connect authorized devices through a private overlay, require visitor-side software for non-HTTP access, or ask you to operate the public relay yourself.
These distinctions determine whether a tool works for the intended workload. A webhook sender needs a public HTTP endpoint. A private administration console may be safer behind an authenticated mesh. A game server may require TCP, UDP, or both. A database client needs the correct raw transport and should rarely be exposed without strict access controls.
Pricing, traffic allowances, endpoint reservation, regional availability, custom domains, concurrency, access controls, and protocol availability can vary by plan or client version. Localtonet product capabilities in this guide were verified against our maintained documentation on August 20, 2026. The supplied evidence for this revision did not include dated snapshots of every competitor's primary documentation, so volatile third-party limits are not presented as verified facts. Confirm them with the vendor on the date of your evaluation.
The ngrok baseline: what an alternative is replacing
Before comparing alternatives, define which part of ngrok you use. Ngrok is not only a command that creates a temporary development URL. Its broader platform includes endpoint creation, HTTP and TCP use cases, traffic inspection, application delivery controls, authentication features, custom domains, and production-oriented gateway capabilities. Exact availability depends on the current product and plan.
Endpoint model
An ngrok agent establishes an outbound session from the machine that can reach the local application. An edge endpoint then receives remote traffic and forwards it through that session. This generally avoids configuring inbound port forwarding on the local router, but the local agent and target service still have to remain available.
Typical use cases
Common use cases include receiving webhooks during development, previewing a local website, testing mobile applications against a developer machine, sharing an API, and forwarding supported TCP applications. Ngrok's public endpoint documentation has historically centered on HTTP, HTTPS, TCP, and TLS-oriented behavior rather than a generic public UDP tunnel. Anyone requiring UDP should verify the current documentation rather than assuming TCP coverage applies to UDP.
Access controls
Depending on the selected product and plan, ngrok can provide edge or application access controls in addition to whatever authentication the application already implements. An alternative should be assessed against the specific control you rely on, such as identity policies, basic authentication, source restrictions, certificate behavior, or application-layer authorization.
Endpoint persistence
Temporary endpoints are convenient for short development sessions, but integrations often store callback URLs. A webhook provider, OAuth configuration, or third-party API may stop working if the address changes after a reconnect. When comparing an alternative, test whether the assigned hostname or port persists under the exact plan and configuration you intend to use.
Relevant limitations
No baseline feature should be assumed to be universal. Endpoint counts, traffic policies, domain options, protocol support, inspection features, and production controls can be plan-dependent. Ngrok also remains a managed dependency unless you select a different architecture. If the real requirement is private device networking or complete control of the relay, a public development tunnel may be the wrong baseline altogether.
How this comparison is structured
This guide compares connectivity models instead of assigning a single score. A numeric ranking can hide disqualifying details, such as missing UDP support, mandatory visitor software, or the need to operate a public server.
Each product is evaluated across the following questions:
- Deployment model: Is the relay managed by the vendor, hosted by the user, or available in both forms?
- Exposure model: Does it create public endpoints, private connectivity, or both?
- HTTP support: Can an ordinary browser or webhook sender reach a published web service?
- Raw TCP support: Can a standard TCP client connect directly, or is a special visitor-side connector required?
- UDP support: Is a public UDP endpoint explicitly documented, or is UDP available only inside a private mesh?
- Visitor requirements: Does the remote user need an agent, identity client, SSH command, or private-network membership?
- Operations: Who patches, secures, monitors, and scales the relay?
- Endpoint behavior: Does the address survive reconnects, and is persistence plan-dependent?
- Security: Which access controls exist at the tunnel, network, and application layers?
A service may proxy TCP only when the visitor runs a companion client, while another service may expose a directly reachable public host and port. Likewise, private-network routing can carry TCP and UDP between authorized devices without creating any public listener. Verify the exact connection path, not just the protocol name in a feature list.
Twelve ngrok alternatives to evaluate in 2026
1. Localtonet
Localtonet is our managed multi-protocol tunneling and proxy platform. The Localtonet client on your device establishes an outbound connection to a selected Localtonet relay. This lets you expose a reachable local service without inbound router port forwarding, a public IP address, conventional VPN setup, or an inbound firewall listener.
Our documented tunnel categories include HTTP/S, TCP, UDP, TLS, combined UDP/TCP, File Server, HTTP and SOCKS5 proxy modes, and VPN Manager. Standard HTTP, TCP, UDP, combined UDP/TCP, and TLS tunnels point to a local IP address and port on, or reachable from, the connected client device.
File Server works differently because its target is a local folder path. Its Default subtype provides a browser-based file manager, SFTP supports standard file-transfer clients and automation, and WebDAV can mount the published folder through supported operating-system file managers. Proxy tunnels are different again: the connected device becomes the proxy exit node rather than forwarding traffic to a conventional local IP and port.
VPN Manager is our actual private mesh VPN feature. It includes granular firewall rules and can bridge local LANs. Standard Localtonet tunnels should not be described as VPN connections because they publish a selected service instead of joining devices to a private mesh.
A Localtonet configuration is not active merely because it was created. You must select the appropriate device token and an available relay server, create the configuration, and press Start. Access remains available only while the selected client is connected and the tunnel is running. Available regions, options, and plan allowances should be checked in the current dashboard.
2. Cloudflare Tunnel
Cloudflare Tunnel uses an outbound connector, cloudflared, to connect an origin to Cloudflare's network. It is especially relevant when the application already uses Cloudflare DNS, Zero Trust policies, and edge services. Public hostnames can route web traffic to local HTTP applications, while private-network routing can make internal address ranges available through Cloudflare's access model.
Its non-HTTP behavior requires precise evaluation. Client-assisted Access connections, private-network routing, and an unrestricted public raw TCP listener are different access paths. A visitor may need cloudflared or another supported Cloudflare client method for non-HTTP applications. Cloudflare Tunnel should not be represented as providing a generic public UDP host and port unless its current documentation explicitly introduces that capability.
Quick Tunnels can help with temporary development, but their current limitations should be checked before use. Named tunnels are the more appropriate comparison for a configured application. Upload-size rules, DNS requirements, Access policies, and plan-dependent controls must be evaluated separately from general bandwidth claims.
3. Pinggy
Pinggy focuses on tunnels initiated through SSH, which can reduce installation work on systems that already have an SSH client. Its published product positioning has included HTTP, TCP, TLS, and UDP tunneling as well as traffic inspection and debugging functions.
It is a candidate for quick command-line development workflows, but protocol availability should be confirmed for the intended plan and connection mode. Persistent addresses, custom domains, geographical choices, tunnel counts, traffic allowances, and collaborative controls are volatile product details and should be verified directly during evaluation.
4. LocalXpose
LocalXpose is a managed tunneling service positioned around HTTP/S, TCP, TLS, and UDP use cases. Its product materials have also described request inspection, replay tools, custom-domain support, a graphical client, and file-serving capabilities.
This makes it a relevant hosted option for teams comparing both web and non-HTTP forwarding. However, do not assume that every capability is present in every plan. This guide intentionally does not repeat the previous claim that paid plans provide unlimited bandwidth because that is plan-sensitive and was not supported by dated first-party evidence supplied for this revision.
5. Tailscale and Funnel
Tailscale is primarily a WireGuard-based private mesh network. Authorized devices join a tailnet and communicate without publishing each service openly to the internet. That model is often a better fit for remote administration, private development environments, and trusted device-to-device access.
Tailscale Funnel selectively publishes an HTTPS service for ordinary public visitors. The device hosting that service must participate in Tailscale, while public visitors do not need the Tailscale client. Funnel is not equivalent to a generic public raw TCP or UDP relay. Its permitted ports, DNS behavior, HTTPS requirements, account eligibility, and policy controls are subject to current Tailscale documentation and should be checked at evaluation time.
6. Playit.gg
Playit.gg concentrates on forwarding traffic to game servers behind NAT. It is a natural candidate when the workload is a supported game rather than a web application. Its agent and hosted relay model can provide public TCP and UDP paths without traditional router port forwarding.
Do not choose the transport based only on the phrase “game server.” Requirements vary by title, server edition, plugin stack, and voice or query features. Minecraft Java primarily uses TCP by default, while Minecraft Bedrock uses UDP. Other games may need TCP, UDP, or both. Confirm the game's networking requirements and Playit.gg's current tunnel availability before deployment.
7. LocalTunnel
LocalTunnel is an open-source client and server project centered on HTTP publishing. Its commonly used hosted workflow can assign an HTTPS URL to a local web service, and the client can fit naturally into Node.js development.
The standard hosted workflow is not a native raw TCP or UDP service. It is most suitable for temporary, low-risk web development where the application's own authentication remains effective. If you operate a LocalTunnel server yourself, you gain configuration control but also accept responsibility for availability, upgrades, TLS, abuse handling, monitoring, and capacity.
8. inlets
inlets is aimed at users who want a tunnel server in infrastructure they control. Its product family has included HTTP and TCP forwarding and integrations for cloud and Kubernetes environments. This can suit organizations that want a dedicated public endpoint and are prepared to operate the server side.
The deployment model is the key difference from a turnkey hosted tunnel. You need a public server, protected credentials, patching, monitoring, capacity planning, and an incident-response process. Product editions and licensing have changed over time, so verify the currently maintained edition and its license before standardizing on it. UDP support should not be inferred from TCP support.
9. zrok
zrok is an open-source sharing platform built on OpenZiti. It offers public and private sharing concepts and can be used through a hosted environment or a self-hosted deployment. Public sharing and private overlay access serve different security and client-compatibility needs.
zrok is worth considering when identity-oriented private sharing or deployment control matters more than reproducing a basic one-command tunnel. The supported share types, transport behavior, visitor requirements, hosted-service limits, and self-hosting architecture should be confirmed against the current zrok documentation before treating it as a raw TCP or UDP replacement.
10. localhost.run
localhost.run is an SSH-initiated service focused on publishing local HTTP applications. It can be attractive when a system already includes an SSH client and the goal is to obtain a temporary web address without installing a dedicated agent.
The command previously shown in this article has been removed because the supplied audit evidence did not include current localhost.run documentation confirming its exact syntax. Follow the current first-party instructions instead of copying an undated command. Stable names, custom domains, authentication, service availability, and paid options should also be checked directly. It should not be treated as a general UDP relay.
11. frp
frp is an open-source reverse proxy that you deploy on infrastructure you control. A public server runs the server component, while a client behind NAT establishes the outward connection and maps selected services. Its established use cases include HTTP, HTTPS, TCP, and UDP proxying.
frp offers control over the relay and configuration, but it does not eliminate cost or operations. You must supply a public server, pay for compute and transfer, protect administrative access, configure authentication and certificates where applicable, monitor availability, and update both sides. Use configuration examples written for the exact frp version you install because formats and features can evolve.
12. Packetriot
Packetriot provides tunnel and hosting-oriented workflows for publishing services behind NAT and firewalls. It may be considered for websites, custom-domain publishing, and TCP forwarding where a managed connection is preferable to operating a reverse-proxy server.
Its current operating-system support, endpoint behavior, protocol coverage, quotas, plan boundaries, and organizational controls should be verified directly. UDP support is not asserted in this guide because it was not established by the supplied dated evidence. A general label such as “enterprise-focused” is not enough to determine compatibility.
Complete capability comparison
The following table is a screening tool, not a substitute for a proof of concept. “Private” means access is limited through an overlay or authorized access path. “Public” means the service can create an internet-reachable endpoint. Cells marked “confirm” identify behavior that should be validated against current first-party documentation and the intended plan.
| Tool | Deployment model | Public or private access | HTTP | Raw TCP | UDP | Visitor-side client | Self-hosting responsibility | Important constraints |
|---|---|---|---|---|---|---|---|---|
| ngrok | Managed edge and agent | Primarily public endpoints, with additional access controls | Yes | Yes, subject to current product and plan | No generic public UDP endpoint documented in the supplied evidence | No for ordinary public HTTP or TCP clients | No | Persistence, domains, limits, and controls can be plan-dependent |
| Localtonet | Managed relay and client | Public tunnels; private mesh through VPN Manager | Yes | Yes | Yes, including combined UDP/TCP configurations | No for public tunnels; VPN participants use the private mesh | No | The selected client must be connected and the tunnel must be running |
| Cloudflare Tunnel | Managed edge with outbound connector | Public web hostnames and private-network access | Yes | Client-assisted or private access, not a generic unrestricted listener | No generic public UDP endpoint established here | No for public web; commonly yes for non-HTTP or private access | No | DNS, Access, connector, and plan requirements vary by workflow |
| Pinggy | Hosted, commonly SSH-initiated | Public tunnels | Yes | Published as supported; confirm current plan | Published as supported; confirm current plan | No for a public endpoint | No | Persistent addresses, regions, and allowances may be plan-dependent |
| LocalXpose | Managed relay and client | Public tunnels | Yes | Published as supported; confirm current plan | Published as supported; confirm current plan | No for a public endpoint | No | Do not assume unlimited bandwidth or universal feature availability |
| Tailscale and Funnel | Managed coordination with device mesh | Private mesh; selected public HTTPS through Funnel | Yes through Funnel or private mesh | Private mesh, not a generic public Funnel listener | Inside the private mesh, not as public Funnel UDP | No for public Funnel visitors; yes for private mesh members | No relay self-hosting assumed | Funnel ports, HTTPS behavior, policies, and eligibility must be confirmed |
| Playit.gg | Managed game relay and agent | Public game-service endpoints | Not the primary focus | Yes for supported configurations | Yes for supported configurations | No beyond the normal game client | No | Match the exact game, edition, ports, and transports |
| LocalTunnel | Hosted HTTP service or self-hosted server | Public HTTP | Yes | No native hosted raw TCP workflow | No | No | Only when self-hosted | Primarily temporary HTTP development; operational guarantees vary |
| inlets | Self-managed relay product | Public endpoints through your server | Yes | Yes in relevant editions | Not established by the supplied evidence | No for published endpoints | Yes | Licensing, maintained editions, and capabilities require current review |
| zrok | Hosted or self-hosted sharing platform | Public and private sharing | Yes for relevant share types | Confirm by share type | Confirm by share type | No for public shares; private sharing may require participation | Optional | Share type and overlay architecture affect compatibility |
| localhost.run | Hosted, SSH-initiated | Public HTTP | Yes | Not positioned here as generic raw TCP | No | No for public web visitors | No | Use current documented syntax; verify stable-name and domain options |
| frp | Self-hosted reverse proxy | Public or restricted according to your deployment | Yes | Yes | Yes | No for normally published endpoints | Yes | You operate, secure, update, monitor, and fund the relay |
| Packetriot | Managed tunnel and client | Public publishing | Yes | Published as supported; confirm current offering | Not established by the supplied evidence | No for public endpoints | No | Verify plans, quotas, client support, persistence, and current protocols |
How the Localtonet workflow differs by target
With Localtonet, begin by identifying what you are connecting. Web servers and APIs normally use an HTTP tunnel. Applications that speak their own protocol use TCP, UDP, combined UDP/TCP, or TLS according to their documented requirements. A folder uses File Server. A device acting as an outbound proxy uses a proxy configuration. Private device networking belongs in VPN Manager.
Install and run the Localtonet client
Run the client on the device that hosts the service or can reach it over the local network. The client creates the outbound connection to our relay infrastructure.
Authenticate the intended device
Select the device-specific authentication token associated with the client that will run the tunnel. Treat the token as a credential and never publish it in screenshots, examples, or source control.
Select an available relay server
Choose from the server or region values currently offered in the dashboard. Do not rely on hardcoded region names because availability can change by plan or deployment.
Create the appropriate configuration
For an HTTP, TCP, UDP, combined UDP/TCP, or TLS tunnel, enter the local IP address and port. For File Server, select the subtype and local folder path. Proxy modes use the connected device as the exit node rather than a conventional local target.
Start the tunnel
Creating the configuration does not start it. Press Start and wait for the tunnel to become active before testing the assigned public URL or host and port.
Stop or delete access when finished
Stop the tunnel when external access is no longer required. Delete configurations that should not be reused. The endpoint works only while the selected client is connected and the tunnel is running.
For a folder-sharing workflow, follow the Localtonet File Server documentation. The documented sequence is to install the app, open the File Server Tunnel page, choose the Process Type, select the AuthToken and server, enter the folder path, and press Start.
HTTP and File Server tunnels can use a random subdomain, a supported custom subdomain, or a custom domain. These Process Type choices serve the same target content at a public HTTPS address. Check current documentation before changing DNS because exact custom-domain requirements can evolve.
A practical workflow for evaluating your shortlist
A feature table can eliminate obvious mismatches, but it cannot prove that a tunnel works correctly on your network. Test two or three candidates with the same harmless target, the same protocol, and the same acceptance criteria.
Write down the non-negotiable requirements
Record whether the endpoint must be public or private, which transport is required, whether visitors can install software, whether the address must remain stable, and whether your team can operate a relay server. Eliminate products that fail any mandatory requirement.
Prepare a harmless local test service
Use a test-only web page or echo service with no credentials, personal files, administration functions, or production data. If you need a basic HTTP target and already have Python 3, create an empty temporary directory and run the following command inside it.
python -m http.server 8000 --bind 127.0.0.1Confirm the local service before tunneling
Open http://127.0.0.1:8000 in a browser or request it with an HTTP client. If the local request fails, fix the application first. A tunnel cannot forward successfully to a service that is stopped, bound to a different address, or listening on another port.
Create and start one candidate tunnel
Follow the vendor's current first-party instructions. Record the selected protocol, local target, public endpoint, access policy, client version, plan, and evaluation date. Do not paste authentication tokens or private endpoints into shared notes.
Test from an independent network
Use a separate device or network so the test does not accidentally reach the service through localhost or the LAN. For public HTTP, verify the public hostname in a browser. For raw protocols, use the application's normal client. For private access, verify that only an enrolled and authorized device can connect.
Test authentication and denial behavior
Confirm that an authorized user succeeds and an unauthorized user is rejected. Test the application login as well as any tunnel or identity policy. If source restrictions are configured, verify both an allowed and denied source.
Restart and reconnect
Restart the tunnel client, temporarily disconnect the network, and restore it. Record how long recovery takes, whether manual action is needed, and whether the hostname or public port changes. This reveals whether the endpoint is suitable for saved webhook URLs and persistent integrations.
Stop access and confirm teardown
Stop the tunnel and verify from the independent network that the public or private path no longer reaches the target. Remove test DNS records, revoke temporary credentials, delete unnecessary configurations, and stop the harmless local service.
Record comparable results
For each candidate, document startup complexity, visitor requirements, endpoint stability, reconnect behavior, authentication, log visibility, teardown behavior, protocol compatibility, and who must maintain the relay. Also record current plan constraints directly from the vendor rather than relying on an old comparison article.
For production evaluation, add support arrangements, health monitoring, audit requirements, incident response, data handling, capacity limits, domain ownership, certificate behavior, and failure modes. Multiple selectable regions do not automatically mean that one tunnel fails over between regions. Treat redundancy as unproven unless the vendor documents and you test the failover design.
Security requirements for any tunnel or private-access tool
Do not expose an unauthenticated administration panel, database, development debugger, file browser, source-code directory, model control interface, or AI-agent endpoint merely because a tunnel makes it easy. Tunneling changes reachability. It does not replace authentication, authorization, patching, or secure application design.
Use layered authentication
Keep application authentication enabled even when the tunnel platform provides an access policy. The application should enforce its own permissions, session handling, and role boundaries. Tunnel-level controls can add another layer, but they should not become the only protection for a sensitive application unless the architecture has been deliberately reviewed.
Apply least privilege
Expose only the service and port needed for the test. Do not publish a whole device, management network, or broad private subnet when one application is sufficient. In a private mesh, use firewall rules and identity policies to limit which users and devices can reach each target.
Protect credentials
Device tokens, tunnel credentials, private keys, API keys, and access tokens must not appear in repositories, screenshots, terminal recordings, issue trackers, or public examples. Use the product's supported secret handling, rotate credentials after suspected exposure, and remove credentials associated with retired devices.
Keep development features out of public reach
Debuggers, stack traces, hot-reload consoles, database dashboards, and framework development servers may reveal environment variables, source paths, or internal details. Use a harmless test target when comparing tools. If a real development application must be shared, disable unnecessary debugging and require authentication first.
Limit exposure time
Start a public tunnel only when it is needed and stop it afterward. This reduces the period in which scanners, automated attacks, or accidental visitors can reach the service. For Localtonet, remember that a saved tunnel configuration is distinct from a running tunnel, and the endpoint depends on the selected client remaining connected.
Choose private access when public access is unnecessary
If every user is known and can join an authorized network, a private mesh may be preferable to a public endpoint. Tailscale is centered on this model. Localtonet VPN Manager provides a separate private mesh option with granular firewall rules and LAN bridging. This is distinct from publishing an HTTP, TCP, UDP, TLS, or File Server tunnel.
Troubleshooting tunnel and private-access failures
| Symptom | Likely cause | What to check |
|---|---|---|
| The public endpoint returns a connection error | The local service is stopped or the target port is wrong | Test the local IP and port from the tunnel device before checking the relay |
| The tunnel is configured but unreachable | The tunnel was created but not started, or the client is disconnected | Check client connectivity and tunnel runtime status |
| The tunnel connects to the wrong application | Another process owns the configured port | Inspect listening processes and confirm the application's actual bind port |
| Localhost works, but a container target fails | The tunnel client and application do not share the same network namespace | Use an address reachable from the client environment rather than assuming its localhost is the container's localhost |
| A domain does not resolve | DNS is missing, incorrect, or still cached | Verify the current vendor instructions, DNS record, hostname spelling, and resolver result |
| HTTP works but the application protocol does not | The wrong tunnel type was selected | Confirm whether the application requires HTTP, TLS passthrough, raw TCP, UDP, or both TCP and UDP |
| Cloudflare web access works but a raw client does not | The selected path requires client-assisted Access or private routing | Confirm whether the visitor needs cloudflared, WARP, or another supported client path |
| A private mesh peer cannot connect | The device is not enrolled, authorized, online, or permitted by policy | Check peer status, identity, route advertisement, firewall policy, and target listener |
| A webhook stops after reconnecting | The public hostname changed | Check endpoint persistence and update the callback only after confirming the current address |
| TCP succeeds but UDP fails | UDP was not configured or the provider does not expose it in that mode | Verify explicit UDP support, the destination port, local firewall behavior, and application transport |
Work from the inside out. First prove that the application is listening. Next prove that the tunnel client can reach the target. Then confirm that the client is authenticated and connected to the relay. Finally, test the public endpoint or private access path from a genuinely remote device.
A successful DNS lookup does not prove that a service is running. Likewise, a connected tunnel does not prove that the local listener is healthy. Separate name resolution, relay connectivity, target reachability, authentication, and application behavior during diagnosis.
Frequently asked questions
What is the best ngrok alternative in 2026?
There is no universal winner. Localtonet is a strong managed candidate for HTTP, TCP, UDP, combined UDP/TCP, TLS, File Server, and proxy workflows. Cloudflare Tunnel fits many Cloudflare-integrated web and private-access deployments. Tailscale emphasizes private mesh networking, Playit.gg focuses on game servers, and frp is relevant when you want to operate the relay yourself.
Does ngrok support UDP tunnels?
The ngrok capabilities established by the supplied evidence cover HTTP, HTTPS, TCP, and TLS-oriented endpoint behavior, not a generic public UDP endpoint. If UDP is mandatory, evaluate a product that explicitly documents UDP for your selected plan and endpoint type.
Is Cloudflare Tunnel a direct replacement for ngrok TCP endpoints?
Not in every workflow. Cloudflare can carry supported non-HTTP traffic through client-assisted Access methods or private-network routing, but those models differ from publishing a directly reachable raw TCP host and port for an ordinary client. Confirm the visitor-side requirements before treating them as equivalent.
Does a public visitor need Tailscale to use Funnel?
No. The publishing device participates in Tailscale, but an ordinary public visitor can reach the HTTPS service exposed through Funnel. Private tailnet access is different and requires authorized participation. Funnel is not a general public raw TCP or UDP relay.
Do all game servers need UDP?
No. Requirements differ by game and edition. Minecraft Java primarily uses TCP by default, while Minecraft Bedrock uses UDP. Other games can require TCP, UDP, or both. Follow the current networking documentation for the exact server you are hosting.
Is a self-hosted reverse proxy cheaper than a managed tunnel?
Not necessarily. Open-source software may have no license fee, but you still need a public server, bandwidth, certificates where applicable, monitoring, updates, backups, security work, and staff time. Compare total operational cost rather than only the software price.
Can Localtonet publish a folder instead of a web application?
Yes. Localtonet File Server publishes a local folder path rather than an IP address and port. Choose the Default browser-based manager, SFTP for compatible clients and automation, or WebDAV for a network-drive style workflow. Apply appropriate permissions and protect access before sharing the endpoint.
Does creating a Localtonet tunnel make it immediately public?
No. Creating the configuration does not start it. You must press Start, and the tunnel remains available only while the selected Localtonet client is connected and the tunnel is running. Stop it when external access is no longer needed.
Test Localtonet against your actual protocol requirements
Choose the correct HTTP, TCP, UDP, combined UDP/TCP, TLS, File Server, proxy, or VPN Manager workflow, verify the local target first, start access from the selected connected device, and stop it when your evaluation is complete.
Get Started Free →
