HomeGenie Windows Service: Remote Access with Localtonet

How HomeGenie and Localtonet fit together

HomeGenie is designed to run on hardware you control. Its backend service hosts a browser interface and connects local automation components, while its automation and AI capabilities can operate on the local server. The project distributes portable release archives for Windows, Linux, macOS, and Raspberry Pi. On Windows, the basic installation model is straightforward: choose the correct release archive, extract it, and launch the included start.bat script.

That local installation and remote connectivity are separate layers. HomeGenie must first be installed, started, and reachable through its local HTTP endpoint. Only after that endpoint works should it be connected to Localtonet. This order matters because a tunnel cannot repair a HomeGenie process that failed to start, selected an unexpected port, or is inaccessible from the device running our client.

With Localtonet, the client application establishes an outbound connection from the Windows device to one of our relay servers. An HTTP tunnel then points to HomeGenie's local IP address and port. This provides a public HTTP tunnel address without requiring inbound router port forwarding, firewall port exposure, a public IP address, or VPN setup. The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running.

Request flow

During local use, a browser connects directly to an address in the form http://<server_ip>:<port>/. During remote use, the browser connects to the public address assigned to the Localtonet HTTP tunnel. Our relay forwards the web traffic through the connected client to the configured local target. HomeGenie still runs on the Windows computer, and its automation environment remains on that system.

A Localtonet tunnel does not turn HomeGenie into a hosted cloud installation, and standard tunneling is not a VPN. If a private mesh network is required instead of publishing one HTTP service, that is a different architecture involving Localtonet VPN Manager. This guide focuses specifically on exposing the HomeGenie web endpoint through an HTTP tunnel.

Prepare the Windows host

Choose a Windows computer that can remain powered on when remote access is needed. HomeGenie and the Localtonet client must both be running for the complete path to work. Windows sleep, shutdown, network disconnection, or service failure will make the remote endpoint unavailable even if the tunnel configuration remains saved in the dashboard.

Before downloading a HomeGenie release, identify the computer's architecture and graphics hardware. HomeGenie publishes multiple Windows x64 variants. The standard win-x64 build is intended for CPU-only use and does not require a dedicated GPU. The win-x64-cuda12 build is intended for supported NVIDIA hardware and requires current NVIDIA drivers. The win-x64-vulkan build is intended to use suitable AMD, Intel, or NVIDIA graphics for applicable AI workloads, with DirectX 12 used for vision acceleration on Windows.

Select the release for the machine you actually intend to use. A larger accelerated build is not automatically better for a server that does not have the required graphics hardware or drivers. For an older PC, a headless server, or an installation focused on ordinary automation rather than accelerated local AI, the standard package is the conservative starting point.

Choose a stable installation directory

HomeGenie's release is portable, so the extracted directory is effectively the installation. Put it in a permanent location before creating a Windows service. Do not register a service while the application is still in a temporary download or extraction directory and then move it afterward. A service definition may rely on the executable path, script path, working directory, or files stored alongside the application.

The account that will run HomeGenie needs appropriate access to the extracted directory and any connected resources that HomeGenie must use. Service accounts do not necessarily have the same mapped drives, user profile, environment, interactive desktop, or file permissions as the Windows account used for the initial test. If HomeGenie works when launched manually but not as a service, this difference is one of the first things to investigate.

Plan for safe testing

During installation, test on the local computer first. Then test from another device on the same LAN if LAN access is part of the intended setup. Do not create a public tunnel merely to determine whether the application starts. Also decide who should be able to reach the interface before enabling remote access. A smart-home control surface can expose sensitive operational information and device controls, so public reachability should be treated as a deliberate security decision.

Install and start HomeGenie on Windows

The initial installation should be performed interactively, even if the final goal is a Windows service. An interactive launch makes startup messages visible and confirms that the selected package works before service isolation adds another layer of variables.

If HomeGenie is already running and the startup script is launched again, the documented behavior is to open another app window connected to the existing session rather than starting a second server. This helps avoid accidentally creating two competing instances during an interactive test.

To stop an interactively launched instance gracefully, focus the terminal window and press CTRL + C. Do this before switching to service operation so that only one HomeGenie process is expected to own the selected HTTP port.

Optional headless behavior

The default startup scripts include --start-browser. That is convenient for a desktop installation, but it is generally unnecessary for a server expected to run without an interactive user. HomeGenie's documented approach for a traditional server-only or headless launch is to edit the startup script and remove the --start-browser argument from the execution command.

Preserve an original copy before making that change, and retest the edited script interactively. Removing the browser-opening argument should change the desktop launch behavior, not the need for the HomeGenie backend process to start and listen on its HTTP endpoint.

Prepare HomeGenie for Windows service operation

A Windows service is useful when HomeGenie must start with Windows and continue running without an open terminal or logged-in desktop session. However, service installation must use the mechanism documented for the exact HomeGenie release. The available evidence for this article confirms that HomeGenie supports Windows Service setup, but it does not establish the current service installer filename, registration command, service name, or removal command.

We therefore do not provide a guessed PowerShell command, sc.exe command, wrapper configuration, or executable flag. Those details can change between releases, and an incorrect command can register the wrong working directory, use an unsuitable account, or leave a service that cannot be cleanly upgraded. Inspect the documentation and service-related files included with the downloaded release, and use the release's own Windows Service procedure exactly as provided.

What to confirm during service registration

Regardless of the release-specific registration mechanism, validate the resulting service in the Windows Services management console. Confirm that its executable or launcher points into the permanent HomeGenie directory, that the configured account can read and write the files HomeGenie requires, and that the startup mode matches the intended unattended operation.

Start the service and check whether it remains in the Running state. A service that starts and immediately stops usually indicates a startup error, a missing dependency, an invalid path, an inaccessible working directory, a port conflict, or an account-permission problem. Check both the service-specific output provided by the package and Windows event information where appropriate.

Do not keep the interactive start.bat instance running while testing the service. If the first instance owns the HTTP port, the service may fail or choose different behavior. Stop the terminal instance with CTRL + C, verify that its process has exited, and only then start the registered service.

Service account differences

A service can behave differently from an application launched from your desktop account. It may have a different home directory, different environment variables, no access to mapped network drives, and different permissions for serial devices, configuration files, media directories, cameras, or other integrations. Use local paths or explicitly available resources where possible, and grant only the permissions HomeGenie actually requires.

If connected hardware or network resources are involved, test those integrations after switching to the service account. A functioning web dashboard proves that the HTTP server is alive, but it does not prove that every automation device, file path, camera, or external integration remains available in the service context.

Find and verify the local HomeGenie HTTP endpoint

HomeGenie exposes a local address in the form http://<server_ip>:<port>/. Port 80 is the default when it is available. If HomeGenie cannot use that port, it can select the first available port starting from 8080. For that reason, assuming either port 80 or 8080 without checking can produce an incorrect tunnel target.

The exact service address is recorded in serviceaddress.txt. Inspect that file in the HomeGenie installation context after the active instance has started. Treat the recorded address as the authoritative target for the current run, especially when another local web server may already occupy a preferred port.

Test from the Windows host

Open the recorded URL in a browser on the Windows computer. Confirm that the HomeGenie interface loads and remains responsive across repeated refreshes. If the server was converted to a service, perform this test after stopping the interactive process and starting only the service. That verifies the service-hosted instance rather than a leftover terminal session.

If the address uses a wildcard, loopback name, or another representation that is not suitable for tunnel configuration, determine the concrete address reachable from the Localtonet client. When both applications run on the same Windows computer, a local loopback target may be appropriate if HomeGenie listens there. When our client runs on another device, use an address that is reachable across the LAN and ensure HomeGenie listens on an applicable interface. Do not assume that a service bound only to loopback can be reached from a different machine.

Test from the local network when necessary

If the Localtonet client will run on the HomeGenie computer, successful access on that computer is the essential baseline. If our client will run on another device, open the HomeGenie URL from that device or perform an equivalent HTTP connectivity test before creating the tunnel. A failure at this stage is a local routing, listening, firewall, or service issue.

Connect HomeGenie remotely with a Localtonet HTTP tunnel

Once the HomeGenie page works locally, create a Localtonet HTTP tunnel. Run our client on the Windows host itself or on another always-on device that can reach the verified HomeGenie address. Running both on the same computer often produces the simplest dependency chain, but a separate client device is valid when local routing and firewall policy permit access.

HTTP tunnels can use a generated random subdomain, a custom subdomain where supported, or a custom domain. These process types serve the same target content at a public HTTPS address. Availability can vary, and custom-domain DNS requirements should always be checked against current Localtonet documentation rather than inferred.

You can manage tunnels from our dashboard or REST API, but this guide does not provide unverified API calls or commands. For current interface details and supported settings, use the Localtonet documentation. Exact options can vary with product updates, client versions, and subscriptions.

Test the complete remote path

Use a phone with Wi-Fi disabled or another genuinely external connection. Opening the public address while still connected to the home LAN may not prove that remote access works. Confirm that the expected HomeGenie interface appears and that ordinary navigation succeeds.

Also test failure behavior deliberately. Stop the Localtonet tunnel and verify that the public endpoint is no longer available. Restart it and confirm recovery. Then, during a suitable maintenance window, restart the HomeGenie service and confirm that both the local page and remote path return. This separates tunnel lifecycle behavior from application lifecycle behavior.

Secure remote HomeGenie access

A local-first application becomes reachable from the internet when connected to a public tunnel. The tunnel removes the need for direct inbound router configuration, but it does not remove the need to protect the application. Before sharing the address, review HomeGenie's current authentication and authorization configuration, use strong credentials wherever supported, and expose only the service that needs remote access.

Do not assume that an obscure URL is an access-control mechanism. Do not publish HomeGenie merely because it is convenient to reach. Anyone permitted to use the remote interface may be able to view automation state or operate connected devices according to the permissions provided by HomeGenie.

Separate the control plane from the target

The Localtonet dashboard controls tunnel configuration and lifecycle. HomeGenie controls its own users, application behavior, automation data, and connected devices. Protect both layers. A secure Localtonet account does not compensate for weak HomeGenie access controls, and strong HomeGenie credentials do not justify exposing a Localtonet device token.

Avoid excessive Windows privileges

Running HomeGenie as a highly privileged service can increase the impact of an application or automation error. HomeGenie's programmable features make careful isolation especially important. Use a restricted account where practical, limit write access to unrelated directories, and avoid granting broad administrative rights merely to make an initial startup problem disappear.

Keep the installation current

Review HomeGenie release notes before updating. Stop the Windows service, protect application data and configuration according to the project's current upgrade guidance, and verify the local endpoint again after the update. A release may change files, dependencies, startup behavior, or service integration. Do not assume that replacing binaries while the service is running is safe.

Routine operation and troubleshooting

Recommended startup order

After a Windows restart, HomeGenie must start successfully, the Localtonet client must connect, and the tunnel must be running. If HomeGenie starts more slowly than the client, the public address may briefly exist while the local target is still unavailable. Test again after HomeGenie finishes initialization rather than immediately modifying the tunnel.

A practical health check follows the same order as installation: confirm the service, read the recorded local address, open the local page, confirm the Localtonet client connection, verify the tunnel state, and finally test the public address.

The public address does not load

First open the exact local address recorded by HomeGenie from the Localtonet client device. If that fails, the tunnel is not the root cause. Confirm the HomeGenie service is running, verify its port, and check whether the address changed after a restart. If HomeGenie selected a different available port because of a conflict, update the tunnel target only after verifying the new endpoint.

If the local endpoint works, check whether the correct Localtonet device is connected and whether the tunnel has been started. Remember that creating a tunnel is not sufficient. Then compare the tunnel's local IP and port with the working HomeGenie target.

HomeGenie works manually but not as a service

This pattern usually points to execution-context differences. Check the service executable path, working directory, service account, file permissions, environment, and access to connected resources. Ensure that the interactive instance was fully stopped before the service attempted to claim the port. Use the service setup supplied with the exact HomeGenie release rather than a generic wrapper copied from an unrelated tutorial.

The interface opens on an unexpected port

Port 80 may already be occupied or unavailable. HomeGenie can select the first free port starting at 8080, so inspect serviceaddress.txt after startup. Do not repeatedly force a port based on assumption. Identify the other listener if a fixed port is operationally required, then follow HomeGenie's current configuration guidance before changing anything.

The tunnel worked before a restart

Confirm that Windows did not put the computer to sleep, that HomeGenie started as expected, and that the Localtonet client reconnected. Check whether the tunnel itself is running. Then verify that HomeGenie's address and port still match the saved tunnel target. A new port selection caused by a temporary conflict can break an otherwise valid tunnel configuration.

The page loads locally on the server but not from another client device

The application may be listening only on a loopback address, Windows Firewall may block LAN traffic, or the two devices may be isolated by network segmentation. If Localtonet runs on the HomeGenie computer, a locally reachable target can still be used. If our client runs elsewhere, it must be able to reach the service over the LAN. Resolve that local path before retrying the public URL.

The HomeGenie desktop window does not appear

A Windows service runs without the normal interactive desktop experience, so the absence of a PWA window does not necessarily mean the backend failed. Open the recorded service address manually in a browser and check the Windows service state. The --start-browser behavior is intended for interactive startup and is not a reliable service-health indicator.

Frequently asked questions