Install a supervised Home Assistant appliance on Raspberry Pi, verify it locally, and prepare remote access without weakening proxy security
This tutorial uses one specific installation path: Home Assistant OS on a Raspberry Pi 4. Home Assistant OS includes Home Assistant Core, Supervisor, and the managed operating system, so there is no separate Supervisor package to install. We cover hardware preparation, writing the operating system image, first boot, onboarding, local verification, backups, updates, and recovery. We also explain the reverse-proxy requirements that must be resolved before placing the Home Assistant interface behind a Localtonet HTTP tunnel.
📋 What's in this guide
Choose an installation type that includes Supervisor
Home Assistant Supervisor is not an independent application that should be cloned from its source repository and attached to an arbitrary Home Assistant deployment. Supervisor manages a container-based Home Assistant Core installation and related applications. Home Assistant communicates with Supervisor, which provides management functions such as changing network settings and installing or updating software.
The supported way to obtain this managed environment is to install Home Assistant OS. Home Assistant OS is the appliance-style installation and includes Supervisor. Home Assistant Container is a different installation type. It runs Home Assistant in a container that you manage, but it does not include Supervisor or the Home Assistant app management experience.
This distinction is important because Supervisor cannot be added to Home Assistant Container merely by downloading the Supervisor repository or starting another container. The repository itself directs end users to the official Home Assistant installation workflow rather than presenting a standalone Supervisor installer.
| Installation type | Supervisor included? | Management model | Use in this tutorial |
|---|---|---|---|
| Home Assistant OS | Yes | Home Assistant manages the operating environment, Core, Supervisor, updates, backups, and apps | This is the selected installation path |
| Home Assistant Container | No | You manage the container host, container lifecycle, updates, and related services | Not used because the tutorial requires Supervisor |
| Supervisor source repository | Not an end-user installation type | Contains project source and development resources | Do not use it as a substitute for Home Assistant OS |
Supervisor provides a management API for communication with Home Assistant, but that does not make it an appropriate public endpoint. This tutorial does not identify, probe, or publish a Supervisor API port. Remote browser access should target the supported Home Assistant web interface only.
Home Assistant installation options can change over time. The current Home Assistant installation overview remains the authority for supported hardware and installation types. The steps below deliberately narrow the scope to a Raspberry Pi 4 running Home Assistant OS rather than trying to combine instructions for physical appliances, virtual machines, and container hosts.
Hardware and network prerequisites
The reference build in this tutorial uses a Raspberry Pi 4 Model B connected to the local network by Ethernet. Ethernet simplifies initial discovery and removes wireless provisioning from the installation path. You can later make network changes through the supported Home Assistant management interface if required.
Gather the following equipment before writing the image:
If the computer has no built-in microSD slot, use a USB card reader. The card will be erased during imaging, so copy off any existing files before continuing. Make sure you can identify the card by capacity and device name so that you do not overwrite another drive.
Prepare the local network
Connect the Raspberry Pi and the administration device to the same trusted home network. Guest wireless networks commonly isolate clients from one another, and some VLAN configurations block local discovery or direct connections between devices. Either condition can prevent onboarding even when both devices have internet access.
The default web address for a fresh Home Assistant OS installation is commonly:
http://homeassistant.local:8123
Port 8123 is the documented default for the Home Assistant web interface in this installation path. If local name resolution does not work, use the Raspberry Pi address assigned by your router:
http://192.168.x.x:8123Replace the example address with the actual local address shown by the router. A customized deployment can use another hostname, address, port, or local HTTPS configuration. Always retain the endpoint that actually works in your environment rather than assuming the default remains unchanged.
Plan where Localtonet will run
Home Assistant OS is an appliance operating system, not a general-purpose Linux host for arbitrary software. This tutorial therefore places the Localtonet client on a separate, continuously available computer that can reach the Raspberry Pi over the local network. That device can be another supported desktop, server, or small computer.
Before considering a tunnel, the future Localtonet device must be able to open the exact Home Assistant local URL. Being connected to the same router is not sufficient if guest isolation, firewall policy, or VLAN rules block the route.
Install Home Assistant OS on Raspberry Pi 4
The official Raspberry Pi workflow uses Raspberry Pi Imager to select and write the correct Home Assistant OS image. Follow the sequence carefully because writing the image destroys the previous contents of the selected storage device.
Install Raspberry Pi Imager
Download and install Raspberry Pi Imager on the computer that will write the microSD card. Start the application after inserting the card into the computer or card reader.
Select Raspberry Pi 4 as the device
In Raspberry Pi Imager, choose Raspberry Pi 4 as the target device. Selecting the correct model prevents an image for another hardware generation from being written accidentally.
Select the Home Assistant OS image
Open the operating-system selector, choose the category for other specific-purpose operating systems, then choose the home assistants and home automation category. Select Home Assistant and the Home Assistant OS image for Raspberry Pi 4 or Raspberry Pi 400. Use the 64-bit image presented for this hardware path.
Select the microSD card
Choose the card by its displayed device and capacity. Verify this selection before continuing. The write operation erases the selected device, and choosing the wrong disk can destroy unrelated data.
Write and verify the image
Begin the write operation, approve the erase warning, and allow Raspberry Pi Imager to complete both writing and verification. Do not remove the card or disconnect the reader while either operation is active.
Eject the card safely
After verification succeeds, eject the microSD card through the operating system and remove it from the reader. Insert it into the powered-off Raspberry Pi.
Connect Ethernet and power
Connect the Raspberry Pi to the trusted local network with Ethernet, then connect power. Home Assistant OS starts automatically. A keyboard and monitor are not normally required for the browser-based onboarding path.
Wait for first-boot preparation
Initial startup takes longer than an ordinary reboot because Home Assistant OS prepares the managed environment and starts its components. Allow up to about 20 minutes before treating the installation as unavailable. Do not repeatedly remove power during this stage.
Open the local Home Assistant page
From a device on the same network, open http://homeassistant.local:8123. If that hostname does not resolve, find the Raspberry Pi address in the router’s connected-device list and open http://PI_ADDRESS:8123.
The current Home Assistant OS installation guide for Raspberry Pi should be checked before imaging if you are using a different Raspberry Pi model or storage type. Do not substitute an image filename copied from an old tutorial for the current image offered by Raspberry Pi Imager.
A connection failure during the preparation period does not necessarily mean imaging failed. Wait, confirm that the Pi has power and an Ethernet link, and check whether the router assigned it an address. Repeated power removal during storage initialization can create a second problem.
Complete Home Assistant onboarding
Once the preparation page finishes, Home Assistant presents the onboarding workflow. This creates the initial owner account and establishes basic information for the home. Complete onboarding locally before adding integrations, changing proxy settings, or enabling remote access.
Create the owner account
Enter the name, username, and a unique password for the first account. The first user is the owner and has administrative control. Do not reuse a password from another service or put the password in a browser bookmark, URL, screenshot, or support post.
Set the home location and regional preferences
Review the detected location, time zone, unit system, and currency. Location information supports features such as sun calculations, presence behavior, and local formatting, so correct inaccurate values before continuing.
Choose analytics preferences
Review the analytics and diagnostic choices shown by Home Assistant and select the options appropriate for your household. These choices are separate from Localtonet and do not determine whether remote access works.
Review discovered devices
Home Assistant may identify compatible devices and services on the local network. You can configure relevant discoveries now or defer them. Do not add an unfamiliar device solely because it appears during discovery.
Enter the dashboard and sign in again if requested
Confirm that the dashboard loads and that the owner credentials work. Record the working local URL without including credentials. The official Home Assistant onboarding guide provides additional context for the fields shown during this stage.
Create individual accounts for other people
Do not share the owner account among household members. Create an individual account for each person who needs access so credentials can be changed or removed independently. Reserve administrative access for users who actually need to modify integrations, automations, accounts, backups, network settings, or updates.
Account management and permissions are controlled by Home Assistant, not by the tunnel. Publishing the sign-in page through a remote-access service does not create a separate Home Assistant identity or reduce the permissions of an existing administrator.
Verify the local installation and confirm Supervisor
http://homeassistant.local:8123. Use the Raspberry Pi address if local hostname resolution is unavailable.
Local verification creates a clear diagnostic boundary. A tunnel can forward requests to a working local service, but it cannot complete onboarding, repair a damaged microSD card, start a failed Home Assistant instance, or correct an unreachable VLAN.
Perform all of the following checks before planning remote access:
The presence of a Home Assistant dashboard alone does not prove that Supervisor is installed because Home Assistant Container also provides the main interface. The installation type and Supervisor version in system information provide the relevant confirmation for this tutorial.
Test from the future Localtonet device
Install the Localtonet client later on a separate device that remains powered on when remote access is needed. Before installing anything, use that device to open the same local Home Assistant endpoint. For example, if the Pi address is 192.168.1.50 and the default port is unchanged, test http://192.168.1.50:8123.
If the interface works from a laptop but not from the intended Localtonet device, investigate the local network. Common causes include guest wireless isolation, a firewall on the client device, VLAN policy, an incorrect Pi address, or a route that permits one network segment but not another. Do not disable the entire firewall as a permanent fix. Permit only the required path from the Localtonet device to Home Assistant.
Remote access introduces additional dependencies. Retain the local URL and a way to reach the home network so that Home Assistant can still be administered if the tunnel, relay connection, client device, or public network is unavailable.
Create backups, test recovery, and apply updates
Create a backup before substantial integration changes, storage migration, operating-system updates, or remote-access configuration. A backup is most useful when it is stored away from the same microSD card and when its restore process has been tested.
Create and export a backup
Open Settings, System, Backups in Home Assistant. Create a backup using the options presented by the current Home Assistant OS interface. Give it a descriptive name that identifies the state or maintenance event, but do not include passwords, tokens, private URLs, or other secrets in the name.
Wait for the backup to finish, verify that it appears in the backup list, and download or otherwise copy it to protected storage outside the Raspberry Pi. Keeping the only backup on the same card does not protect against card failure, accidental reimaging, or loss of the device.
Home Assistant backups can contain sensitive configuration, account-related data, integration credentials, automation details, and information about the home. Protect exported backups with access controls appropriate for that sensitivity. Follow the current Home Assistant backup guidance when choosing backup and restore options.
Test restoration without creating duplicate automation activity
A restore test should use compatible spare hardware or an isolated test environment. Do not start a restored copy on the live home network without planning for duplicate automations, duplicate integrations, or two systems attempting to control the same devices.
A practical restore test consists of installing Home Assistant OS on the compatible test target, selecting the backup-restore option during onboarding, providing the backup, waiting for restoration to complete, and confirming that Home Assistant starts. Keep the test target isolated from production devices when duplicate actions could create risk.
Record the backup creation date, Home Assistant version, target hardware, whether decryption credentials were required, and the result of the restore test. Never store a backup password in the same unprotected location as the encrypted backup.
Apply managed updates carefully
Home Assistant OS surfaces updates through its managed interface. Review the update information and release notes shown by Home Assistant, create a fresh backup, and confirm that local administration works before beginning. Avoid starting an update immediately before travel or another period when nobody can reach the hardware.
After an update, verify the dashboard, critical integrations, automations, logs, Supervisor information, and local network endpoint. Then test remote access separately. This order prevents a tunnel symptom from being mistaken for a Home Assistant update failure.
Do not download a Supervisor release asset and manually replace the managed component. Home Assistant OS and Supervisor control their own supported update lifecycle. A source repository release page is not a replacement for the update workflow presented by the installed system.
Plan for storage failure
If the microSD card fails, replace it, write a fresh current Home Assistant OS image for Raspberry Pi 4, boot the system, and use the supported restore option with an off-device backup. Do not depend on recovering files directly from a damaged Home Assistant OS filesystem as the primary recovery strategy.
If you are replacing another Home Assistant installation, do not erase its storage until you have created an appropriate backup, copied it elsewhere, and reviewed compatibility with the destination Home Assistant OS version. Preserve the original system until the restored installation has been verified.
Plan remote access through Localtonet
Localtonet can expose a local web service through an outbound connection to one of our relay servers. This avoids inbound router port forwarding, a public IP address, and a separate VPN setup. An HTTP tunnel points to a local IP address and port and provides a public HTTPS address while the selected Localtonet client is connected and the tunnel is running.
Home Assistant, however, has explicit reverse-proxy security requirements. A generic HTTP tunnel cannot safely be treated as transparent until its header and connection behavior is known. Home Assistant may reject a request when proxy headers are present but the immediate proxy is not configured as trusted.
Understand Home Assistant reverse-proxy requirements
Home Assistant’s HTTP integration documents two related settings for reverse proxies. The use_x_forwarded_for setting controls whether Home Assistant uses the forwarded client address, and trusted_proxies defines which immediate proxy addresses are allowed to supply that information.
The important value is not the public visitor’s address and not automatically the Localtonet relay’s public address. It is the source address Home Assistant sees for the connection that directly reaches port 8123. Depending on how a tunnel client and local network are implemented, that source might be a loopback address, the Localtonet client device’s LAN address, a container-network address, or another narrowly defined intermediary. It must be observed and verified rather than guessed.
Home Assistant also relies on WebSockets for interactive and continuously updated interface behavior. A usable HTTP tunnel must handle WebSocket upgrades correctly. The public scheme must be conveyed correctly through X-Forwarded-Proto or equivalent behavior where Home Assistant depends on it, and the forwarded client chain must be protected from spoofing.
Host handling matters as well. A tunnel may preserve Home Assistant’s local Host value, send the public tunnel hostname, or provide a separate forwarded-host header. The expected behavior must be confirmed because applications can use the host and scheme when validating requests or producing absolute URLs.
| Compatibility item | Why Home Assistant needs it | What must be verified |
|---|---|---|
| WebSockets | Supports live interface communication and state updates | The Localtonet HTTP path must pass WebSocket upgrades and long-lived connections |
| X-Forwarded-For | Allows Home Assistant to identify the originating client through a trusted proxy | Confirm the header format, append behavior, and protection against client-supplied spoofed values |
| X-Forwarded-Proto | Communicates that the public browser connection used HTTPS when the local target uses HTTP | Confirm whether Localtonet supplies the header and what value Home Assistant receives |
| Host handling | Can affect request validation, redirects, and generated URLs | Confirm whether the public hostname or local target host is sent to Home Assistant |
| Immediate source address | Determines the narrow value permitted under trusted_proxies |
Observe the exact source Home Assistant reports for the proxy connection |
| TLS termination | Separates the public HTTPS connection from the local HTTP connection | Confirm where TLS ends and whether the local target is HTTP or HTTPS |
Never trust an entire home subnet, container range, or private-address block merely to make an error disappear. Any device inside a trusted range may be able to submit forwarded client information. Trust only the exact proxy address or smallest necessary range established by the real connection path.
Why this guide does not provide a paste-ready trusted proxy block
The verified Localtonet product information available for this revision establishes how HTTP tunnels are created and how their lifecycle works. It does not establish the exact Host behavior, WebSocket behavior, forwarded-header format, spoofing controls, or source address Home Assistant observes for every supported Localtonet client environment.
Those values can vary with topology. Publishing one guessed address under trusted_proxies could either fail to work or grant trust to more devices than intended. For that reason, this article does not present an exact Home Assistant HTTP configuration block as if it were universal.
Before activating a permanent direct HTTP tunnel, verify the behavior against current Localtonet HTTP tunnel documentation or obtain confirmation for the specific client platform and network layout. Compare that behavior with the official Home Assistant HTTP integration documentation.
Prepare the Localtonet HTTP tunnel after compatibility is confirmed
Once the required behavior has been confirmed for the actual deployment, use the documented Localtonet sequence below. The local target for an unchanged installation is the Raspberry Pi address on port 8123, not homeassistant.local unless that hostname reliably resolves from the Localtonet client device.
Install and run the Localtonet client
Install our client on the separate device that passed the local Home Assistant reachability test. Keep that device powered on and connected whenever remote access is required.
Authenticate the client device
Use the device-specific authentication token assigned to that client. Keep the token private and never place it in Home Assistant configuration, screenshots, source repositories, or troubleshooting posts.
Select an available relay server
Choose a relay server or region currently available in the Localtonet dashboard. Do not copy a server code from another installation because availability can vary by account, plan, version, or region.
Create an HTTP tunnel to Home Assistant
Select the HTTP tunnel family. Enter the Raspberry Pi local address and the verified Home Assistant port, which is normally 8123 on this fresh installation. Choose a random subdomain, custom subdomain where available, or custom domain according to the current options.
Apply the verified Home Assistant proxy configuration
Configure the Home Assistant HTTP integration only with the exact proxy source and header behavior established for this deployment. Validate the configuration before restarting Home Assistant. Do not enable forwarded-header trust without a confirmed proxy source.
Start the tunnel
Creating a tunnel does not start it. Review the target and use the Start button. The public endpoint is available only while the selected client remains connected and the tunnel is running.
Verify the public endpoint from an external network
Turn off Wi-Fi on a phone or use another external network, then open the assigned HTTPS address. Confirm the Home Assistant sign-in page, authentication, dashboard loading, live state updates, and navigation between multiple views.
Inspect logs during the first remote test
Open Settings, System, Logs in Home Assistant before or immediately after the test. Look for reverse-proxy rejection messages, authentication failures, WebSocket errors, repeated reconnects, or requests reported from an unexpected source address.
If Home Assistant reports that a request came from a reverse proxy that is not configured, do not solve the problem by trusting every private address. Record the reported immediate source, confirm that it belongs to the intended tunnel path, verify forwarded-header behavior, and add only the narrow value justified by that evidence.
A successful sign-in page is not a complete test. Open a dashboard whose entity states change, navigate between settings pages, leave the page open long enough to observe live updates, and reconnect after the phone changes networks. WebSocket incompatibility may appear only after the initial HTML loads.
The official Home Assistant remote-access guidance explains the security implications of making the instance reachable outside the home network.
Secure accounts and the public access path
A public URL changes reachability, not authorization. Home Assistant still controls user authentication and permissions. Treat the URL as discoverable and protect the application as though unknown internet users can reach its sign-in page.
Enable multifactor authentication
Home Assistant supports multifactor authentication modules, including time-based one-time passwords where enabled by the installation. Each user should open their profile and configure an available multifactor method for their own account. Follow the current Home Assistant multifactor authentication documentation for the exact setup and recovery behavior.
Test multifactor authentication in a private browser session before depending on it remotely. Keep recovery information in protected storage. Do not take an unprotected screenshot of a QR code or secret because anyone who obtains that secret may be able to generate valid codes.
Review accounts and administrator access
Use separate accounts for separate people. Remove accounts that are no longer needed and avoid granting administrative access for routine dashboard use. Review account access after household changes, device loss, contractor work, or credential exposure.
Home Assistant credentials and the Localtonet device token protect different systems. Home Assistant credentials authenticate a person to the application. The Localtonet token identifies the client device establishing the tunnel. Do not reuse, combine, or publicly disclose either type of credential.
The current Home Assistant authentication documentation should be used for account, login, and recovery procedures. Changing a tunnel target or relay server does not repair an invalid Home Assistant password.
Limit network access to the required target
The Localtonet device needs outbound internet connectivity and local access to the Raspberry Pi web interface. It does not need unrestricted administrative access to the router, storage systems, cameras, or every device in the home. Apply the narrowest practical local firewall and VLAN rules.
Point the tunnel directly at the intended Home Assistant endpoint. Do not target a router administration page, container dashboard, broad reverse proxy, host-management interface, or Supervisor API simply because it runs on a nearby address.
Use the tunnel lifecycle intentionally
Stop the tunnel when temporary remote maintenance is finished. Delete obsolete configurations if they will not be reused. If continuous access is required, include the Localtonet client device in normal operating-system updates, restart planning, physical security, and uptime monitoring.
A generated or unusual subdomain is not an authentication control. Keep Home Assistant authentication enabled, use multifactor authentication, remove unused accounts, protect the owner account, and monitor logs for unexpected requests or failed sign-ins.
Troubleshoot installation and remote-access failures
The Raspberry Pi never appears on the network
Confirm that the Ethernet cable is connected before power-up, the router port is active, and the power supply is suitable for the Raspberry Pi 4. Check the router’s connected-device list for a new address. If no device appears after the initial preparation period, power down cleanly, rewrite the correct Raspberry Pi 4 Home Assistant OS image, and allow Raspberry Pi Imager to verify the card.
Repeated write or verification failures suggest a bad card, card reader, adapter, or USB connection. Replace one component at a time rather than repeatedly booting an image that did not verify.
homeassistant.local does not resolve
Local hostname discovery is not available on every client or network. Find the Raspberry Pi address in the router’s DHCP or connected-device list and open http://PI_ADDRESS:8123. If the IP address works, Home Assistant is running and the problem is local name resolution.
The address responds, but onboarding does not appear
Confirm that the browser is reaching the Raspberry Pi and port 8123 rather than a different local service. Allow first-boot preparation to finish, refresh the page, and test from another browser. If the connection is refused consistently, check power, storage imaging, and the address assigned by the router.
The dashboard works, but Supervisor cannot be found
Open the system information view and check the installation type. A Home Assistant Container installation can provide the dashboard without Supervisor. If the installation type is not Home Assistant OS, do not attempt to attach the Supervisor repository. Back up the existing deployment and follow an appropriate migration path to Home Assistant OS.
Home Assistant works from one local device but not the Localtonet device
This is a local routing or policy problem. Check whether the Localtonet device is on a guest network, isolated wireless network, separate VLAN, or host firewall profile. Test the Raspberry Pi address directly from that device. Fix the narrow local path before creating or changing a tunnel.
The public URL returns a reverse-proxy error
Inspect Home Assistant logs for the immediate source address and the exact rejection message. Do not add a broad subnet automatically. Confirm that the source belongs to the intended Localtonet path and verify how forwarded headers are constructed before changing trusted_proxies.
The sign-in page loads, but the dashboard disconnects or stops updating
This can indicate a WebSocket problem even though ordinary HTTP requests work. Review browser behavior and Home Assistant logs, then confirm that the HTTP tunnel supports WebSocket upgrades for this configuration. Do not treat the initial page load as proof of full compatibility.
The public endpoint redirects to the wrong scheme or hostname
Check the verified Host and forwarded-protocol behavior. A public HTTPS connection may terminate at the tunnel edge while the local Home Assistant target remains HTTP. Incorrect or missing proxy information can affect redirects and generated URLs. Use only configuration supported by the observed Localtonet behavior and Home Assistant HTTP documentation.
The Localtonet client is connected, but the endpoint is unavailable
Confirm that the HTTP tunnel was started. Creating the definition is not enough. Then verify that the selected client is the same device that can reach Home Assistant, the relay selection is valid, and the local IP address and port still match the tested endpoint.
The tunnel stopped after the client device restarted
Remote access depends on both the client connection and the tunnel’s running state. After a restart, confirm that the Localtonet client is active and authenticated, then inspect the tunnel state. Automatic-start behavior can depend on platform, client version, and local configuration, so test restart recovery instead of assuming it.
The interface opens, but authentication fails
Reaching the sign-in page confirms that requests are arriving at Home Assistant. Use the supported Home Assistant account or recovery workflow rather than changing tunnel families, relay servers, or ports. Never place a password in the URL or send it in a public support message.
An update breaks local and remote access
Diagnose locally first. Check whether the Raspberry Pi completed its restart and whether the local interface returns. If the installation cannot be recovered through the managed interface, use the off-device backup and the tested reimage-and-restore plan. A tunnel cannot repair a Home Assistant OS startup failure.
Check Raspberry Pi power and storage, the local Home Assistant page, authentication, Supervisor information, reachability from the Localtonet device, the client connection, the tunnel running state, proxy logs, and finally the public URL. This sequence isolates the failing layer without weakening unrelated security controls.
Frequently asked questions
Does Home Assistant OS include Supervisor?
Yes. Home Assistant OS is the managed appliance installation and includes Supervisor. Confirm the result in Home Assistant system information, where the installation type should identify Home Assistant OS and a Supervisor version should be present.
Can I add Supervisor to Home Assistant Container?
No supported procedure in this guide adds Supervisor to Home Assistant Container. Container and Home Assistant OS are different installation types. If Supervisor is required, back up the existing system and follow an appropriate migration to Home Assistant OS rather than cloning the Supervisor repository.
What is the default local Home Assistant address?
For the fresh Home Assistant OS installation described here, use http://homeassistant.local:8123. If the hostname does not resolve, use the Raspberry Pi local IP address with port 8123. Customized installations can differ, so retain the endpoint that actually works.
Can Localtonet run directly inside Home Assistant OS?
This tutorial does not install our client inside Home Assistant OS. Home Assistant OS is a managed appliance rather than a general-purpose host for arbitrary packages. Run Localtonet on a separate supported device that can reach the Raspberry Pi over the local network.
Does a Localtonet HTTP tunnel require router port forwarding?
No. The Localtonet client establishes an outbound connection to our relay server. The tunnel does not require an inbound router forwarding rule or a public IP address.
What should I enter under trusted_proxies?
Enter only the exact immediate proxy address or smallest necessary range verified for the real connection path. Do not assume it is the relay address, Localtonet device address, loopback address, or entire home subnet. Confirm the source Home Assistant observes and verify Localtonet’s forwarded-header behavior first.
Why is there no universal Home Assistant proxy configuration in this article?
A safe configuration depends on the exact source address and on verified Host, WebSocket, X-Forwarded-For, and X-Forwarded-Proto behavior. Those values are not established universally for every Localtonet client topology, so publishing a guessed block could fail or create an unnecessarily broad trust boundary.
Should I expose the Supervisor API separately?
No. Supervisor is managed through Home Assistant in this installation. This tutorial exposes only the supported Home Assistant web interface after the proxy requirements have been satisfied.
Does creating a tunnel start it automatically?
No. Creating a Localtonet tunnel and running it are separate lifecycle actions. Use the Start button after reviewing the target. The endpoint remains available only while the selected client is connected and the tunnel is running.
What should I check first when remote access fails?
Open Home Assistant locally first. Then test the same local endpoint from the Localtonet device. If both succeed, check the Localtonet client connection, tunnel running state, target address, Home Assistant proxy logs, and finally the public URL.
Prepare your Home Assistant remote-access path with Localtonet
Install Home Assistant OS, confirm Supervisor, create an off-device backup, enable strong account protection, and verify the local interface from the intended Localtonet device. Then use our HTTP tunnel workflow after confirming the exact reverse-proxy behavior required by your Home Assistant deployment.
Get Started Free →
