Expose a Self-Hosted Chat Server with Localtonet

The remote access problem after self-hosting chat

Platforms such as Mattermost, Rocket.Chat, and Matrix let an organization operate chat infrastructure on hardware it controls. The application might run directly on a workstation, a home server, a virtual machine, a container host, or a small device inside a private network. After installation, the service commonly listens on a local address such as 127.0.0.1, localhost, or a private LAN address. That is enough for local testing, but it does not automatically make the service reachable by remote users.

Traditional publication can involve obtaining a public IP address, forwarding ports through a router, changing firewall rules, configuring DNS, and maintaining a public-facing reverse proxy. Those tasks may be impractical on a network behind carrier-grade NAT, a temporary development environment, or an internet connection where the operator does not control the router. They also create additional infrastructure that must be secured and maintained.

Localtonet uses a different connection direction. Its client application runs on a device that can reach the chat server and establishes an outbound connection to a Localtonet relay server. The resulting tunnel maps a public endpoint to the selected local IP address and port. Because the connection begins from inside the network, the workflow does not require inbound port forwarding, firewall changes, VPN setup, or a public IP address.

Choose the tunnel type that matches the chat service

Most self-hosted chat interfaces are accessed through a browser or a mobile client that connects to a web endpoint. An HTTP tunnel is therefore the natural starting point when the chat deployment already exposes an HTTP service on a known local port. HTTP and File Server tunnels support Random Sub Domain, Custom Sub Domain, and Custom Domain process types. Each process type serves the configured content at a public HTTPS address.

A raw TCP tunnel is appropriate only when a required component uses TCP directly rather than an HTTP application endpoint. UDP can be used for a service that genuinely expects UDP, while a combined UDP/TCP tunnel is available when the same application workflow requires both transports. Localtonet also documents TLS tunnels. The exact protocol selection should follow the chat platform's own deployment architecture rather than an assumption that every port in a multi-service stack should be public.

Do not expose databases, internal administration ports, container control sockets, private service-discovery endpoints, or message-broker ports merely because they are reachable from the Localtonet client device. A typical deployment should publish only the user-facing endpoint that remote clients need. Databases and internal dependencies should remain private unless the application vendor provides a specific, secured reason to expose them.

Prepare the local chat service

Before creating a tunnel, verify that the chat application works from the device that will run the Localtonet client. Open the local interface in a browser or test the relevant local port with an appropriate client. Confirm the exact local IP address and port, and check whether the application is listening only on loopback or on a LAN interface.

If the application and Localtonet client run on the same operating system, a loopback target may be sufficient. If the chat server runs on another device, the Localtonet client must run somewhere that can reach that device's private address. Container deployments require particular care because a port inside a container is not necessarily reachable from the host. Publish or map the intended application port according to the container platform's documentation, then test it from the Localtonet client device before creating the tunnel.

The public address may also need to be reflected in the chat platform's own base URL, callback URL, trusted-origin, or proxy settings. Those names and requirements vary among Mattermost, Rocket.Chat, Matrix implementations, and other chat servers. Consult the current documentation for the selected platform instead of copying settings from a different product. Localtonet creates the network path, but it does not replace application-level configuration required by the chat software.

Create and start the Localtonet tunnel

The following workflow follows the maintained Localtonet tunnel lifecycle. Interface labels and available choices can vary by client version, plan, and current dashboard configuration. In particular, relay server codes and region values should always be selected from the current product interface rather than copied from an article.

Understand availability and tunnel lifecycle

A Localtonet tunnel is available only while the selected client or device is connected and the tunnel is running. Creating a configuration in the dashboard is not the same as starting it. If the host device sleeps, loses network connectivity, shuts down, or stops the Localtonet client, the public endpoint cannot continue forwarding traffic to the local chat service.

This lifecycle is useful for temporary demonstrations and development reviews because access can be stopped when the session ends. For an always-needed team service, the device, chat application, Localtonet client, and local network all need suitable operational monitoring. Localtonet-specific uptime guarantees, benchmark results, and performance percentages are not stated here because they are not provided in the maintained product context. Test the complete deployment under the workload and client mix expected by your organization.

Localtonet also provides platform-wide Token/Tunnel webhooks for connection-state monitoring. These webhooks can send a JSON request when a token or tunnel in a selected Token Group changes to Connected or Disconnected. The payload identifies the relevant tunnel ID or authentication token, the action date, whether the event concerns a Token or Tunnel, and the Connected or Disconnected status. These platform events are distinct from File Server webhooks, which concern file-level operations and are not part of a normal chat-server tunnel.

Secure the public chat endpoint

Removing inbound port forwarding does not remove the need for application security. Once a chat endpoint has a public URL or host and port, internet users may be able to reach its sign-in page or protocol listener. Keep the chat platform updated, require strong authentication, restrict account creation, remove default credentials, and grant administrative privileges only where necessary.

Use the chat application's supported access controls, identity-provider integrations, invitation policies, rate limits, and session controls where available. Review upload permissions and file-retention behavior if users can exchange attachments. Back up the chat database and uploaded content according to the platform's own recovery documentation. A tunnel provides connectivity, but application data protection, moderation, account lifecycle management, and disaster recovery remain the operator's responsibility.

Apply least privilege to network exposure. Publish the user-facing application port, not the database or internal management plane. If the chat stack has multiple services, identify which component is intended to receive public traffic and keep the remaining components on private container or LAN networks. Use IP restrictions and other access controls where they are supported by the relevant product configuration and subscription plan. Do not assume that every option is available on every plan.

For custom domains, verify the current Localtonet DNS instructions before changing records. Exact DNS requirements can change and are not specified in this article. Generated or selected subdomains can provide a simpler starting point when supported, while a custom domain may be appropriate after the chat deployment has been validated.

Practical validation checklist

Test the deployment from outside the server's local network. A phone using mobile data is often a simple way to confirm that a public endpoint is not succeeding only because of local routing. Verify that the public address loads, account authentication works, and an ordinary non-administrator account has only the intended permissions.

Next, restart the chat application and confirm that it returns cleanly. Stop and start the Localtonet tunnel so operators understand the difference between the saved configuration and its active state. If the chat platform uses a configured public base URL, verify that generated links, redirects, and sign-in callbacks use the intended public address. Check the platform's own logs for configuration errors without publishing those logs or exposing credentials.

Finally, document an internal operating procedure. Record which device runs the client, which local service and port are targeted, who may start or stop the tunnel, and how access should be revoked. Store sensitive values separately from ordinary documentation. This makes the setup easier to maintain without turning device tokens or administrative credentials into shared knowledge.