Expose a Self-Hosted Chat Server with Localtonet

What this tutorial covers

This tutorial covers publication of an existing, locally functional chat deployment. It does not install Mattermost, Rocket.Chat, a Matrix homeserver, or their databases. Before introducing a tunnel, your application must start successfully, connect to its dependencies, and allow two local sessions to exchange messages.

Localtonet changes the direction of the network connection. Our client runs on a device that can reach the application and establishes an outbound connection to a Localtonet relay. A running HTTP tunnel provides a public HTTPS address for the configured local web service. This does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Use the service only where your organization permits outbound tunneling and public application access.

A public endpoint is a route, not a replacement for application configuration. The chat server may still advertise an internal hostname, reject the browser’s public origin, or generate an unusable real-time connection address. Creating the tunnel and configuring the application are distinct tasks, and both must pass verification.

Prerequisites and local checks

Choose a maintenance window and retain an administration path that does not depend on the new public address. A local console or authorized private-network connection is important because an incorrect public URL can break browser administration or identity-provider login.

Record the application version, deployment method, local listener, current public URL, existing reverse proxy, and configuration source. Configuration might come from a file, environment variables, a database, or a deployment management system. Editing a file that is overridden by the running service will not change the effective configuration.

Install and authenticate the Localtonet device

Install and run our client for the device’s operating system, then authenticate the device using its device-specific token. The selected device must be the machine that can reach the tunnel target. Keep the client running and confirm that the device is connected before relying on the public endpoint.

The supported general path is installation, client startup, device authentication, and selection of that device in the tunnel configuration. The supplied evidence does not establish a current Linux package name, download command, authentication prompt, service unit, or unattended-installation procedure. We therefore do not provide a guessed shell command or token flag. Complete the operating-system-specific installation using the current product instructions associated with the HTTP tunnel documentation.

Keep device tokens out of source control, screenshots, shared shell history, and ordinary operating notes. A token identifies the client device; it is not the chat application’s login password and should not be distributed to chat users.

Test the exact intended target

If the application and Localtonet client run directly on the same host, the target may be a loopback listener. The following is an illustrative check for an application listening on port 8065, not a port to assume for every deployment:

curl --connect-timeout 5 --max-time 15 \
  --silent --show-error --output /dev/null \
  --write-out 'HTTP %{http_code}\n' \
  http://127.0.0.1:8065/

A successful response proves only that an HTTP listener answered. A redirect may be intentional; a login page does not prove that the database, account login, or messaging works. Open the same address in a browser where possible, sign in with a test account, and exchange messages with a second session.

If our client runs on another machine, 127.0.0.1 refers to that client machine, not the chat host. Use the chat host’s reachable private address instead. A service bound exclusively to loopback cannot accept a connection from another LAN device.

Check containers and reverse proxies

For containers, identify the host-side published port. A container’s internal port is not automatically a host listener, and loopback inside one container is not the host’s loopback. Test from the same network environment in which the Localtonet client actually runs.

If the existing deployment uses a reverse proxy for routing, authentication, or application security controls, target that established entry point rather than bypassing it casually. Record every hop between the Localtonet client and the chat application. This makes forwarding-header and WebSocket failures much easier to diagnose.

Chat compatibility depends on the deployment

Mattermost and Rocket.Chat commonly expose browser interfaces and HTTP APIs, but their settings, deployment layouts, and real-time transports are application-specific. Matrix is a protocol ecosystem with multiple homeserver implementations. Its client access and federation requirements must be evaluated separately.

Our platform supports HTTP/s, TCP, UDP, combined UDP/TCP, and TLS tunnel families. That does not establish that an arbitrary media deployment will work after forwarding a few ports. Some media architectures require advertised addresses, separate relays, or multiple endpoints, and need their own deployment recipe.

For Matrix, do not change an established server identity simply to match a temporary tunnel hostname. Client discovery, server naming, media access, and federation require implementation-specific planning. This guide does not provide a Matrix federation or voice/video configuration.

Configure the HTTP tunnel

The steps below summarize the supported general Localtonet workflow. They are not represented as the exact numbered sequence of the current HTTP documentation, whose full contents were not supplied. Confirm the current HTTP form and ordering in the HTTP tunnel setup instructions before publishing a UI-specific walkthrough.

Record the resulting HTTPS origin without placing device credentials in the record. For the examples below, https://chat.example.com is a placeholder. Replace it with the exact assigned address; do not configure the literal example hostname.

Endpoint testing belongs after setup. Stop and delete operations belong to maintenance and retirement, not to the tunnel-creation sequence. If configuring the application requires time, keep exposure limited to an approved test window and do not invite users until the acceptance checks pass.

Integrate the application with its public URL

A reproducible integration requires a specific application version and deployment method. The supplied research does not contain a version-specific primary deployment guide for any named chat server. It therefore cannot substantiate a currently verified Mattermost, Rocket.Chat, or Matrix recipe. In particular, a version mentioned in a third-party comparison is not sufficient evidence for its configuration semantics.

The following Mattermost example explains the configuration boundary concretely. It is applicable only after confirming that your installed release supports the named settings and that your deployment uses a file-based configuration with no overriding environment variables or database-managed settings. It should not be treated as a version-pinned production procedure.

Define a narrow integration target

Consider an already running, single-node Mattermost instance on a Linux host, with our client on that same host and a working local HTTP listener at 127.0.0.1:8065. The proposed scope is browser login, text messaging, and application-served attachments. Calls, federation, external storage, and identity-provider changes are excluded from the initial acceptance test.

Before changing anything, record the actual Mattermost version and configuration location. Preserve the existing configuration and its permissions. Do not replace the complete configuration with a short example, because doing so would discard database connections, secrets, and unrelated application settings.

Set the public URL in the authoritative configuration

In Mattermost configuration schemas that expose these settings, the relevant public URL field is ServiceSettings.SiteURL. A separate ServiceSettings.WebsocketURL field can specify a different WebSocket address. The intended same-origin arrangement is a public HTTPS site with its real-time endpoint on that same public hostname, rather than a URL containing localhost or a private IP.

This illustrative fragment shows the intended relationship, not a complete configuration file or a verified schema for the latest release:

{
  "ServiceSettings": {
    "SiteURL": "https://chat.example.com",
    "WebsocketURL": ""
  }
}

Leaving a separate WebSocket URL empty is appropriate only when the installed release derives the correct same-origin address. Confirm that behavior in the effective configuration and in the browser’s network panel. If an existing deployment uses an explicit WebSocket address, investigate why before changing it. Do not retain an internal ws:// address on an HTTPS browser page.

A public HTTPS URL does not require replacing a working local HTTP listener with the public hostname. These values serve different purposes: the local target tells our client where to connect, while the public URL tells the application what users should see.

Preserve the host, scheme, and real-time route

With an existing local reverse proxy, the proxy must route the ordinary application requests and the real-time endpoint to the same intended deployment. WebSocket upgrades require appropriate handling of the upgrade request, and long-lived connections must not be terminated by unsuitable proxy timeouts.

Exact proxy directives, forwarding headers emitted by Localtonet, and trusted-proxy settings are not established by the supplied evidence. We therefore do not prescribe an Nginx or Caddy block, a proxy-hop count, or a wildcard trust setting. Keep the existing known-good proxy configuration and verify the public path before altering trust behavior.

For a same-origin browser deployment, the browser page, API requests, and WebSocket request should use the intended public hostname. Do not enable wildcard cross-origin access as a workaround for a wrong site URL. If the browser reports an origin rejection, inspect the actual origin and the installed application’s effective configuration first.

Apply the change through the existing service manager

Configuration changes must reach the running process. Use the same supervisor or deployment system that currently starts the application. Do not launch a second chat process manually, and do not assume that saving a file automatically reloads it.

For a Linux installation already managed by systemd with a unit specifically named mattermost, the following conditional example restarts that existing service and checks its state:

sudo systemctl restart mattermost
sudo systemctl status mattermost --no-pager

These commands do not install a unit or establish that your deployment uses that name. For containers, apply changes through the existing container definition. Environment-variable changes generally require replacement of the affected container rather than merely restarting the old process. The exact service name and recreation command must come from that deployment’s configuration.

After restart, confirm the listener still answers locally and that the effective public URL is correct. A locally requested page may now redirect to the public hostname intentionally. Distinguish that expected redirect from a refusal, crash, or redirect loop.

Know what must be confirmed before production

A release-specific primary check must establish the installed version, authoritative configuration source, public URL behavior, real-time URL behavior, origin validation, proxy trust, and restart requirements. Without those checks, the example remains a test plan rather than a supported production recipe. Keep an unchanged recovery copy and do not broaden public access to compensate for an unresolved configuration error.

Verify the complete workflow

Test from the local listener outward, then test the application rather than only the landing page. Use ordinary test accounts and harmless content. Keep credentials and session cookies out of command output and shared diagnostics.

Check HTTP responses and redirects

From an external network, inspect the first public response without automatically following redirects:

curl --connect-timeout 5 --max-time 15 \
  --silent --show-error --dump-header - --output /dev/null \
  https://chat.example.com/

Replace the placeholder with your endpoint. Expect a valid HTTPS connection and an application response or intentional redirect. If a Location header appears, it should not expose a private address, container hostname, or obsolete domain. Do not use options that disable certificate validation to make a failed check appear successful.

Verify authentication and authorization

Use a phone on mobile data or another external connection. Confirm that scripts, styles, and images load without certificate or mixed-content errors. Sign in, sign out, and sign in again with an ordinary account. Check that private channels remain private and that the account cannot reach administrative functions.

Test invitations and password-reset links if configured. Identity-provider callbacks are a separate configuration dependency: both the application and provider must agree on the public callback address. Do not weaken callback validation to accommodate a wrong hostname.

Verify real-time messaging

Open two independent sessions, preferably on different networks. Send messages in both directions without refreshing either page. Test channel changes, direct messages, and presence or typing indicators where supported.

For a deployment using WebSockets, inspect the browser’s network panel. A conventional successful HTTP/1.1 WebSocket upgrade returns 101 Switching Protocols. Also verify ongoing frames and message delivery; a successful initial upgrade alone does not prove a stable connection. Watch for repeated reconnect attempts or requests to internal addresses.

Test interruptions, attachments, and clients

Temporarily disconnect an external test client, send a message from the other session, then reconnect. Confirm that the client resynchronizes according to the application’s normal behavior. Repeat after an idle period, since an unsuitable intermediate timeout may not appear during a short test.

Upload a harmless attachment, preview it, and download it from the second account. Confirm that generated links use a reachable public route and retain the expected authorization. Test the supported desktop and mobile clients separately, including notifications where configured.

During an approved maintenance window, stop and restart the tunnel and observe recovery. Record which functions passed, the installed application version, local target, public hostname, and test time. Do not describe untested federation or media as working.

Troubleshoot by connection layer

Change one layer at a time. If local requests fail, switching relays will not repair the application. If the local listener works but the device is disconnected, editing the application URL will not reconnect the tunnel. If only a custom hostname fails, compare its DNS configuration with current Localtonet requirements before altering the local target.

Use timestamps to correlate browser failures with application and existing proxy logs. Preserve response codes and error categories, but redact authorization headers, cookies, tokens, email addresses, and message content before sharing diagnostics.

Security, operations, and rollback

A public HTTPS endpoint is not a private membership boundary. Configure registration, invitation rules, account permissions, and authentication in the chat application. Use multifactor authentication or an identity provider where supported, remove development credentials, and keep administrator accounts separate from everyday messaging accounts.

Operate the complete dependency chain

Document which device runs Localtonet, what starts the chat process, and how dependencies recover after a host restart. Avoid inappropriate sleep settings for an always-needed service. Do not assume that a saved tunnel automatically becomes active after every restart; confirm device connectivity, tunnel state, and external message delivery.

Our platform-wide Token/Tunnel webhooks report Connected and Disconnected state changes for a selected Token Group. The request contains Id, ActionDate, Type, and Status. The Token/Tunnel webhook documentation describes this monitoring integration. Connection-state events complement, but do not replace, an application-level messaging test.

Maintain backups and software

Back up the database, uploaded files, configuration, and required secrets using the chat platform’s supported method. A database-only backup may omit attachments or encryption material. Protect backups from ordinary application accounts and test restoration in isolation.

Maintain the operating system, chat application, plugins, database, reverse proxy, and Localtonet client. After updates, repeat the local and external acceptance checks. Record version changes so a new failure can be correlated with an actual deployment change.

Roll back a failed publication change

1. Stop the tunnel to end new public access through that endpoint while investigating.
2. Use the retained local administration path to restore the previous application configuration, including public URL, explicit real-time URL, origin rules, and any proxy changes.
3. Restore the previous authoritative environment or deployment definition if it overrides file settings.
4. Restart or redeploy the application through its existing supervisor, then verify local login and two-session messaging.
5. Restore any identity-provider callback changes made for the test. Do not leave obsolete callbacks enabled unnecessarily.
6. Restart public access only after identifying the cause and repeating acceptance tests.

Configuration rollback is not permission to restore an old database blindly. Avoid combining this publication change with a database migration or application upgrade. If those changes are unavoidable, use the platform’s supported recovery procedure and account for messages written since the backup.

Retire access deliberately

Stop the tunnel when public access is no longer needed and delete obsolete configurations. For a retired or compromised device, revoke or replace affected device access through the supported account workflow. Rotate application credentials and sessions separately if they were also exposed. Removing a tunnel does not undo messages, invitations, or credentials already disclosed to someone else.

Frequently asked questions