A security-first path from a local AI gateway to controlled HTTPS access
Self-hosting an AI agent gives you direct responsibility for its runtime, credentials, tools, updates, and network exposure. This guide explains how to prepare an OpenClaw installation, verify it locally, and publish its web gateway through a Localtonet HTTP tunnel without opening an inbound router port. It also covers traffic boundaries, authentication, tunnel lifecycle management, backups, upgrades, rollback planning, WebSocket validation, and focused troubleshooting. OpenClaw commands and configuration fields can change between releases, so this revision deliberately avoids unverified project-specific commands and directs you to confirm version-sensitive values in the current OpenClaw documentation.
📋 What's in this guide
What this guide does and does not assume
OpenClaw is treated here as a self-hosted application that provides a local web gateway. The exact OpenClaw package name, installation command, supported Node.js version, configuration schema, default port, service name, container image, model providers, messaging channels, pairing behavior, and diagnostic commands are version-sensitive project details. They must be checked against the current OpenClaw repository and documentation for the release you intend to install.
That distinction is important because copying a command from an older tutorial can install an incompatible runtime, expose a container on every network interface, overwrite a current configuration, or start a service under the wrong account. This article therefore provides a complete deployment workflow without presenting unverified OpenClaw syntax as current fact. Where an action depends on OpenClaw itself, follow the installation path documented for your selected release and record the actual values shown by that installation.
Earlier versions of this article assumed a particular gateway port, file path, daemon name, Docker image, and command set. Those details were not supported by current primary OpenClaw evidence supplied for this revision. Use the loopback address and port reported by your installed version instead of assuming an old default.
The Localtonet portion is based on our current platform behavior. The Localtonet client on your device creates an outbound connection to a Localtonet relay server. An HTTP tunnel then provides a public HTTPS address that forwards requests to the local IP address and port you configure. You do not need inbound router port forwarding, firewall changes, a VPN, or a public IP address.
Creating a Localtonet tunnel does not automatically make it run. You must start it after creation. The selected device must remain connected, the OpenClaw gateway must remain available on the configured local target, and the tunnel itself must remain running. If any part of that chain stops, remote access stops as well.
Understand the traffic and trust boundaries
A self-hosted agent can store configuration or conversation data on your own machine, but that does not mean all data remains there. Prompts, messages, files, tool results, or metadata may travel to services you configure. These can include an external model provider, a messaging platform, a webhook sender, and the relay infrastructure carrying remote requests.
For browser access through Localtonet, the traffic path is conceptually:
- A remote browser connects to the public HTTPS address assigned to the tunnel.
- The request reaches the selected Localtonet relay.
- The relay forwards it through the outbound connection maintained by the Localtonet client.
- The client sends it to the loopback-bound OpenClaw gateway on the same device.
- OpenClaw processes the request and may contact configured model or messaging providers.
Review the privacy, retention, and account settings of every model, messaging, storage, and automation provider you connect. Local storage reduces some dependencies, but external processing still occurs whenever the agent sends information to a configured third-party service.
Prerequisites and deployment decisions
Prepare the host before installing OpenClaw. A stable deployment is easier to secure when you decide where it will run, which operating-system account owns it, and which external services it may reach before importing credentials.
| Requirement | What to confirm | Why it matters |
|---|---|---|
| Supported host platform | Confirm the operating systems and CPU architectures documented by the current OpenClaw release. | A package or container built for another platform may fail or behave differently. |
| Supported runtime | Install the exact Node.js or other runtime range required by that OpenClaw release. | Using an assumed runtime version can cause installation or startup failures. |
| Dedicated user account | Choose a non-administrator account with access only to required files and tools. | Least privilege reduces the impact of an unsafe tool call or compromised integration. |
| Model access | Confirm the provider supported by your OpenClaw version and create credentials through that provider. | Model credentials can permit billable requests and may expose submitted content. |
| Local gateway binding | Confirm that the gateway can bind to a loopback address and identify its actual local port. | The tunnel should target a local-only listener rather than a service exposed to the LAN. |
| Localtonet account and client | Create an account and install a supported Localtonet client on the device that can reach OpenClaw. | The selected client must stay connected while the tunnel is in use. |
| Backup location | Prepare protected storage for non-secret configuration and restoration notes. | A tested backup simplifies recovery after an update or host failure. |
Localtonet currently supports clients for Windows, macOS, Linux, Android, Docker, and other documented installation paths. Choose the installation option shown on the current Localtonet website for your platform. Do not copy device authentication tokens into shell history, scripts, screenshots, tickets, or public configuration repositories.
Choose the exposure model before installation
For this workflow, the preferred network shape is a gateway listening only on the host loopback interface. A loopback listener is reachable from applications on the same host but is not directly reachable from another device on the local network. Localtonet then forwards the public HTTPS address to that loopback target.
If OpenClaw runs in a container, do not publish its gateway on all host interfaces merely to make tunneling convenient. A Docker mapping such as an unspecified host address followed by a published port commonly listens beyond loopback. Use the current OpenClaw container documentation to confirm an officially supported loopback-only publication method, container port, volume layout, and startup sequence. Because those project-specific details were not available in the evidence for this revision, this article does not provide a Docker command.
If you cannot determine which process owns the gateway port or whether it listens on loopback, stop before creating a public tunnel. Resolve the local binding first. A tunnel is not a substitute for securing the application behind it.
Install and configure OpenClaw safely
Use only the installation path documented for the specific OpenClaw release you have selected. Avoid combining commands from old npm, source-build, container, or service-manager tutorials. Each method may use a different configuration location, user account, update procedure, and restart mechanism.
Record the release and supported installation method
Select a current OpenClaw release from the project's primary repository or documentation. Record the version, supported runtime range, operating-system requirements, installation method, and release notes. This record becomes the basis for later upgrades or rollback.
Create a least-privileged runtime account
Run OpenClaw as a regular operating-system user rather than an administrator or root account. Grant access only to folders, executables, browsers, and services the agent genuinely needs.
Install the required runtime and OpenClaw release
Follow the current project instructions for your chosen package, source, or container path. Do not substitute a newer runtime merely because it is available. Verify that installation finishes without dependency or permission errors.
Configure the model provider
Select only a provider supported by the installed release. Enter its credential through the secure mechanism documented by OpenClaw. Do not place API keys in source control, command examples, screenshots, or shared backup archives.
Bind the gateway to loopback
Use the current OpenClaw configuration method to bind the web gateway to a loopback address such as 127.0.0.1, if that method is officially supported. Record the actual port reported by OpenClaw. Do not assume a port copied from an older article.
Enable OpenClaw authentication
Configure the gateway authentication mechanism supported by your release. Generate a unique credential, store it in a password manager or secret store, and confirm that unauthenticated requests are rejected before remote exposure.
Start OpenClaw using the documented method
Start it interactively for the first verification. Save the startup output and note the listening address, port, configuration path, log location, and any warnings. Configure background startup only after the local test succeeds.
Delay messaging integrations until the gateway works
Configure one boundary at a time. First prove that OpenClaw starts and responds locally. Next prove that model authentication works. Then create remote browser access. Add Telegram, Discord, or another messaging integration only after the core service is stable.
This order makes failures easier to isolate. If an agent does not answer through a messaging platform, you can determine whether the failure belongs to OpenClaw, the model provider, the messaging provider, or the public tunnel instead of changing all four at once.
Do not reuse unverified channel keys, pairing commands, default policies, or configuration fragments from an older OpenClaw installation. Telegram settings are managed through Telegram and OpenClaw. Discord gateway intents are managed in the Discord Developer Portal. Discord intent settings do not exist in Telegram BotFather.
Verify OpenClaw locally before exposure
Local verification is the most important checkpoint in this workflow. Localtonet can forward traffic only to a service that is already running and reachable from the client device. If the application fails locally, changing tunnel settings will not repair it.
Confirm the process remains running
Use the process or service tools appropriate for your operating system and installation method. Check for immediate exits, restart loops, runtime incompatibility, missing files, and permission errors.
Confirm the listening address and port
Inspect the OpenClaw startup output or your operating system's socket list. The expected result is the configured loopback address and the actual gateway port. An all-interface listener should be corrected before proceeding.
Open the local gateway
On the OpenClaw host, browse to the exact loopback URL shown by the running gateway. Confirm that the expected interface loads without certificate, redirect, or asset errors.
Test authentication
Verify that an unauthenticated session cannot reach protected controls. Then sign in with the OpenClaw credential and confirm that a valid session works.
Run a minimal model request
Submit a harmless request that does not invoke shell, browser, file, email, or messaging tools. Confirm the response and inspect logs for model authentication, quota, or network errors.
Record a known-good baseline
Save the OpenClaw version, runtime version, local URL, service owner, startup method, and log location. Do not include secret values in this operational record.
Create the Localtonet HTTP tunnel
Once OpenClaw works on loopback, install and run the Localtonet client on the same device or on a device that can securely reach the local target. Using the same host is the simplest way to keep the OpenClaw gateway bound to loopback.
HTTP tunnels support public HTTPS addresses and web application traffic. Localtonet also supports WebSocket traffic, which is relevant if the installed OpenClaw interface uses a WebSocket connection for live updates or control messages.
Install and run the Localtonet client
Choose the current installation option for your operating system from the Localtonet website. Run the client on the device that can reach the verified OpenClaw loopback service.
Connect the device using its token
Use the product's normal client authentication flow and select the corresponding device token in the dashboard. A token identifies the client device that runs the tunnel. Keep it private and never place it in article examples, command history, screenshots, or source code.
Open the HTTP tunnel page
Sign in and open the Localtonet HTTP tunnel page. Choose a Process Type offered by the current dashboard: Random Sub Domain, Custom Sub Domain, or Custom Domain. These options serve the same target through a public HTTPS address, but availability can vary by plan.
Select the device and relay server
Select the AuthToken for the connected Localtonet client and choose an available relay server from the current dashboard. Do not copy a server code from an old tutorial because available server values can change.
Enter the verified local target
Set the local IP address to the loopback address used by OpenClaw, commonly 127.0.0.1. Enter the actual gateway port you verified from the installed OpenClaw release. Do not assume the historical port from a previous guide.
Create the tunnel
Review the process type, selected token, relay server, target IP, and target port, then create the tunnel. Creation saves the configuration but does not mean the tunnel is running.
Start the tunnel
Press Start for the new tunnel. Wait for it to show as connected and use the assigned public HTTPS address. The tunnel remains available only while the selected client is connected and the tunnel is running.
The current Localtonet Free plan lists one HTTP, TCP, or UDP tunnel, 1 GB of bandwidth per month, and a 30-minute tunnel timeout. It is suitable for short development and demonstration sessions, not uninterrupted permanent access. Current paid tunnels list unlimited bandwidth and no tunnel timeout. Confirm the current plan details before relying on a tunnel for ongoing operation.
Localtonet currently lists Basic Authentication on the Free plan. Other controls, including IP whitelisting and SSO, are listed with paid tunnel capabilities. Available controls can vary by plan or dashboard version. Use the strongest access restrictions available for your account, but keep OpenClaw's own authentication enabled because tunnel-level and application-level controls protect different boundaries.
Verify authenticated remote access
Do not treat the appearance of a public URL as proof that the deployment is correct. Test from a device on a different network, such as a phone with Wi-Fi disabled. This avoids accidentally loading the local service through your home or office network.
Confirm the tunnel is running
Check that the Localtonet client is connected and that the specific HTTP tunnel shows as running. A saved but stopped tunnel cannot forward requests.
Open the HTTPS address remotely
Load the assigned URL from an external network. Confirm that the browser uses HTTPS and that the response is the expected OpenClaw interface rather than a relay, timeout, or unrelated local service page.
Test the unauthenticated path
Use a private browser window and verify that protected OpenClaw functionality is unavailable until the required authentication succeeds. If tunnel-level authentication is enabled, verify that boundary as well.
Authenticate and perform a harmless request
Sign in through the remote address and repeat the minimal non-tool request used during local verification. Avoid testing privileged tools until basic remote access is stable.
Validate WebSocket behavior if required
If OpenClaw uses WebSockets, inspect the browser's developer tools while loading the remote interface. Confirm that the WebSocket request upgrades successfully and remains connected. Repeated disconnects, failed upgrades, or mixed-content errors indicate an application URL, authentication, or proxy compatibility issue that needs investigation.
Test failure behavior
Stop the tunnel and confirm the public URL no longer reaches OpenClaw. Start it again and verify recovery. Then stop OpenClaw while leaving the tunnel running and confirm that the resulting backend failure is distinguishable from a stopped tunnel.
Harden the self-hosted agent
An AI agent with access to files, browsers, shell commands, email, calendars, or third-party accounts has a larger security impact than a read-only website. Treat every tool, message, web page, attachment, and skill as a possible untrusted input.
Protect secrets
- Never commit model keys, bot tokens, gateway credentials, or Localtonet device tokens to version control.
- Do not pass long-lived credentials on command lines when a supported secure input or secret-store mechanism is available.
- Sanitize screenshots, logs, shell history, configuration excerpts, and support bundles before sharing them.
- Rotate a credential immediately if it appears in a public repository, chat message, recording, or screenshot.
- After rotation, restart or reload the application using its documented procedure and verify that the old credential no longer works.
Limit what remote users can trigger
Authentication establishes who may connect, but authorization determines what they may do. If the current OpenClaw release supports approval prompts, allowlists, per-tool controls, or isolated workspaces, configure them using the current project documentation. Begin with tools disabled and add only the capabilities needed for the intended workflow.
Do not expose a multi-user agent merely by sharing one gateway credential. Use application-supported identities and authorization if available. If your release does not provide adequate user separation, treat it as a single-user service and do not share the endpoint.
HTTPS, tunneling, and login controls do not make email content, web pages, attachments, tool output, or incoming messages trustworthy. An authenticated agent can still process hostile instructions embedded in external content. Require human approval for sensitive actions and restrict access to credentials, files, and commands.
Operate, update, back up, and retire the deployment
Service startup and restart behavior
Once interactive verification succeeds, configure OpenClaw to start in the background using the service mechanism officially supported by your installation method. Do the same for the Localtonet client using the current Localtonet instructions for your platform. Do not assume service names or commands from another operating system or an older package.
Reboot the host as a controlled test. Verify in order that the OpenClaw process starts, the loopback gateway responds, the Localtonet client connects, and the tunnel runs as expected. A client can be connected while a specific tunnel remains stopped, so check both states separately.
Logs and monitoring
Keep the log locations documented with your deployment record. During an incident, correlate timestamps across:
- OpenClaw startup and application logs
- Operating-system service logs
- Model-provider request or account logs, where available
- Messaging-provider bot or application logs, where available
- Localtonet tunnel status and request logging available to your plan
Avoid enabling or sharing verbose logs without checking whether they contain prompts, headers, cookies, tokens, filenames, message contents, or personal information.
Back up non-secret configuration
Before an upgrade, back up the documented OpenClaw configuration, prompts, workspace material, and any other state your release identifies as necessary for restoration. Exclude credentials where practical and store them separately in an encrypted secret store. If a configuration file mixes secrets with ordinary settings, protect the entire backup as sensitive.
Record the installed version, runtime version, installation method, gateway binding, port, service account, enabled integrations, and restoration sequence. A backup is useful only if you can restore it, so test recovery on an isolated host or disposable environment when possible.
Upgrade and rollback
Read release and migration notes
Check for runtime changes, configuration migrations, security fixes, renamed commands, and breaking integration changes.
Record and back up the known-good state
Save the current version and protected configuration before modifying packages, containers, or service files.
Stop public access
Stop the Localtonet tunnel during maintenance so users and webhook senders cannot reach a partially migrated application.
Apply the documented upgrade
Use the update procedure for the original installation method. Do not mix package-manager, source, and container upgrade paths.
Repeat local verification
Confirm process health, loopback binding, authentication, model access, and a harmless request before restoring remote access.
Restart and test the tunnel
Start the Localtonet tunnel, repeat authenticated remote and WebSocket tests, and monitor logs for regressions.
Roll back if validation fails
Stop remote access, restore the previous supported release and compatible configuration, then repeat local verification. Do not restore an older application over a configuration that has undergone an incompatible migration unless the project documents that path.
Stopping or deleting the tunnel
Use Stop when you want to suspend public access but preserve the tunnel configuration for later use. Delete the tunnel when the endpoint is no longer needed. Stopping OpenClaw alone does not remove the public tunnel configuration, and disconnecting a client does not delete it.
When retiring the complete deployment, stop and delete the Localtonet tunnel, remove or disconnect the client device if appropriate, revoke unused model and messaging credentials, disable application startup, and archive or securely erase local state according to your retention requirements.
Focused troubleshooting and failure isolation
Work from the local application outward. Changing Localtonet settings cannot fix an OpenClaw process that has stopped, and changing OpenClaw configuration cannot start a Localtonet tunnel.
| Symptom | Likely boundary | What to check |
|---|---|---|
| The local OpenClaw URL does not load | OpenClaw process or local binding | Check process status, startup logs, runtime compatibility, listening address, actual port, and local firewall behavior. |
| Local access works but the public URL times out | Localtonet client or tunnel lifecycle | Confirm the selected device is connected, the tunnel is started, and the configured target matches the verified loopback IP and port. |
| The public URL reaches the wrong application | Incorrect target port | Identify the process listening on the configured port and compare it with OpenClaw's startup output. |
| The page loads but live updates fail | WebSocket or application URL handling | Inspect browser developer tools for failed upgrade requests, authentication failures, mixed content, redirects, or immediate disconnects. |
| Remote authentication fails but local authentication works | Proxy-aware application behavior | Check cookies, redirects, expected public origin settings, and current OpenClaw reverse-proxy guidance. Do not guess configuration keys. |
| The tunnel stops after a short session | Plan limit or client availability | Check the current plan. The Free plan currently lists a 30-minute tunnel timeout, 1 GB monthly bandwidth, and one HTTP, TCP, or UDP tunnel. |
| Access fails after a reboot | Service startup sequence | Verify OpenClaw starts, the local gateway responds, the Localtonet client connects, and the saved tunnel is running. Check each stage separately. |
| The model rejects requests | Model provider | Check the selected provider, credential status, account limits, supported model configuration, and provider-side errors. |
| A Telegram bot receives messages but OpenClaw does not answer | Telegram or OpenClaw channel configuration | Check the bot token, chat permissions, OpenClaw logs, and the current OpenClaw Telegram instructions. Do not look for Discord intents in BotFather. |
| A Discord bot reports disallowed intents | Discord application configuration | Review the intents required by your current OpenClaw Discord integration in the Discord Developer Portal, then restart or reconnect according to current project instructions. |
| New configuration has no effect | OpenClaw reload or service behavior | Check whether the current release supports hot reload for that setting. If not, restart it using the documented method and inspect startup errors. |
| Remote access suddenly returns an authentication error | Credential or session lifecycle | Check whether application, tunnel-level, model, or messaging credentials were rotated or expired. Identify the failing layer before replacing secrets. |
A practical isolation sequence
- Verify the OpenClaw process and its logs.
- Verify the loopback listener and local browser access.
- Verify OpenClaw authentication and a minimal model request.
- Verify the Localtonet client is connected.
- Verify the HTTP tunnel target and running state.
- Verify HTTPS access from a separate network.
- Verify WebSocket traffic if the interface requires it.
- Test messaging or webhook integrations last.
Privacy and data-handling checklist
Before placing real information into the agent, document where each category of data can travel. Avoid the absolute claim that everything remains on your hardware. The answer depends on the model, channels, tools, storage services, tunnel features, and logging options you configure.
| Data category | Possible destination | Control to review |
|---|---|---|
| Prompts and model context | OpenClaw host and configured model provider | Provider retention, training, regional processing, credentials, and account settings |
| Chat messages | Messaging provider, OpenClaw host, and model provider | Channel permissions, message retention, user authorization, and provider privacy settings |
| Files and tool output | Local disk, model provider, or connected application | Filesystem scope, approval controls, redaction, and upload behavior |
| Remote HTTP traffic | Remote browser, Localtonet relay, and OpenClaw host | HTTPS, access controls, request logging, authentication, and plan features |
| Credentials | Local secret storage and the service that issued each credential | Storage permissions, rotation, revocation, backup exclusion, and audit history |
| Operational logs | Application, operating system, providers, and enabled tunnel logging | Retention, redaction, access permissions, and secure deletion |
Frequently asked questions
Can I use a fixed OpenClaw port from an older tutorial?
Do not assume it. Start your installed OpenClaw release locally and verify the listening address and port from its current configuration, startup output, or operating-system socket list. Enter that verified port as the Localtonet target.
Does creating a Localtonet tunnel start it automatically?
No. Creation saves the tunnel configuration. You must press Start, and the selected Localtonet client must remain connected. The OpenClaw service must also continue listening on the configured local target.
Can I use the Localtonet Free plan for permanent OpenClaw access?
The current Free plan lists one HTTP, TCP, or UDP tunnel, 1 GB of bandwidth per month, and a 30-minute tunnel timeout. It is intended for short development and demonstration sessions rather than uninterrupted permanent access. Review the current plan details before choosing an operating model.
Should I disable OpenClaw authentication if the tunnel uses Basic Authentication?
No. Keep application authentication enabled. Tunnel-level authentication protects the public entrance, while OpenClaw authentication protects the application itself. Layered controls reduce dependence on any single credential or configuration.
Does self-hosting mean my prompts never leave my machine?
Not necessarily. If OpenClaw uses an external model provider, prompts and context may be sent to that provider. Messaging services also process messages sent through their platforms. Review every configured provider instead of relying on a general self-hosted label.
Does Localtonet support WebSockets for an OpenClaw interface?
Localtonet HTTP and HTTPS tunneling supports WebSocket traffic. If your OpenClaw release requires WebSockets, confirm the connection through the remote URL with browser developer tools and investigate failed upgrades, redirects, authentication errors, or disconnects.
What should I back up before updating OpenClaw?
Back up the configuration and state identified by the current OpenClaw documentation, along with a record of the installed version, runtime, startup method, and integrations. Keep secrets separate where possible, protect any mixed configuration as sensitive, and stop the public tunnel during the upgrade.
How do I immediately disable remote access?
Stop the Localtonet tunnel in the dashboard. If compromise is suspected, also stop OpenClaw, disconnect the client if necessary, and rotate affected gateway, model, messaging, and device credentials. Delete the tunnel when it is no longer needed.
Publish your verified local gateway with Localtonet
Confirm that OpenClaw works securely on loopback, then create and start a Localtonet HTTP tunnel for controlled remote HTTPS access without inbound router port forwarding.
Get Started Free →
