Set Up Kiosk Satellite Remote Access with Localtonet

How Kiosk Satellite remote access works

Kiosk Satellite is a free, open-source application designed to turn an Android device into a dedicated Home Assistant kiosk. Its documented capabilities include a five-step guided setup, dashboard selection, kiosk protections, screensavers, gestures, remote administration, and optional integration features. Device behavior can still vary with Android version, manufacturer restrictions, granted permissions, and the features selected during setup.

The part used in this tutorial is Kiosk Satellite's embedded Remote Administration HTTP server. Its documented default port is 2324, and the port can be changed. The root path serves a browser-based administration application. A REST API is available under /api/, a WebSocket is available at /api/ws, and a read-only health endpoint is available at /api/health.

Localtonet does not replace or configure that application service. Our client runs on a trusted device that can reach the tablet and establishes an outbound connection to a Localtonet relay server. An HTTP tunnel then maps a public HTTPS address to the tablet's private LAN address and Remote Admin port. The public tunnel is available only while the selected Localtonet client is connected and the tunnel is running.

This architecture creates several distinct dependencies. Kiosk Satellite must be running and its server must have started. The Localtonet client device must be able to route to the tablet's current LAN address. The client must remain connected to our relay, and the tunnel must be started. Finally, the user must authenticate successfully to Kiosk Satellite. Testing these layers in order makes failures much easier to isolate.

Installation and network prerequisites

Prepare the kiosk and its local network before configuring public connectivity. The evidenced Android requirement is Android 7.0 or newer. Android vendors can customize installation controls, background execution, power management, screen pinning, and other kiosk-related behavior, so compatibility with every tablet model is not guaranteed by the minimum operating-system version alone.

You also need a Home Assistant instance that the Android device can reach from its current network and the credentials required by Kiosk Satellite's setup process. The current project describes a guided five-step wizard that connects to Home Assistant, selects a dashboard, detects optional Voice Satellite functionality, and requests permissions based on the features selected. Any Home Assistant long-lived access token used during setup is a credential and must not appear in screenshots, tunnel labels, shared notes, issue reports, or public URLs.

For the installation itself, use the project's current Kiosk Satellite releases page. Release filenames and requirements can change, so select the APK attached to the release you have reviewed instead of copying a package filename from an older tutorial. At the time represented by the supplied project evidence, the specifically reviewed release is Kiosk Satellite 2026.8.79. Check the current releases page before installation because a newer release may exist.

The Android device must allow installation from the source used to open the APK. Android presents this permission differently across versions and manufacturers. Follow the device's own installation prompt and limit the permission to the necessary browser or file manager. If your device-management policy requires it, remove that permission after installation.

Plan where the Localtonet client will run. It must be installed on a supported, trusted device that can open the tablet's Remote Admin address over the LAN. A desktop, small server, or another continuously available machine on the same routed network can fill this role. Do not assume that a client exists for the tablet itself. Confirm currently available Localtonet client platforms through the current dashboard and documentation.

Information to record securely

Record the installed Kiosk Satellite version, the tablet's current LAN address, the configured Remote Admin port, the device that will run our client, and the person responsible for updates. Keep passwords and tokens in an approved credential store rather than in the same operational note. This distinction makes the non-secret network configuration available to operators without unnecessarily distributing credentials.

Install and configure Kiosk Satellite on Android

After the wizard finishes, verify that the expected Home Assistant dashboard loads on the tablet. Test normal navigation, any intended kiosk exit control, and the features necessary for this installation. The project's Kiosk Mode and Lockdown Mode documentation explains the distinction between persistent kiosk protections and the temporary interaction-blocking lockdown control.

Android remains the final authority over some system controls. The project's kiosk documentation notes, for example, that an ordinary application cannot intercept every physical control in every situation. Evaluate the required level of physical lockdown against the deployment and follow the project's documented device-owner guidance if the kiosk must resist deliberate local escape attempts.

Enable and verify Remote Administration locally

According to the current Kiosk Satellite Remote Management API documentation, the embedded server starts only when remote.enabled is on and remote.password has been set. Turning on the feature without a password is not enough.

You can supply the password through the setup wizard. On an already configured Android device, swipe from the left edge, open Settings, select Device, and then open Remote Administration. Enable the service, set a unique administration password, and confirm the configured port. The documented default is 2324.

Use a password that is not reused for Home Assistant, Localtonet, email, or another kiosk. The Remote Admin interface can change settings, display screenshots, expose logs, operate commands, transfer files when supported and permitted, and export configuration. It should be treated as an administrative origin, not as a read-only public dashboard.

Find the tablet's current LAN address

Obtain the tablet's current IP address from Android's network information or from an authorized network-management interface. Do not assume that the address remains unchanged after a reboot, Wi-Fi reconnection, lease renewal, or movement to another network. If the address changes, the Localtonet tunnel target must be updated unless your network provides a stable assignment.

Test the root administration page from a second device

From a browser on another device connected to the same routed network, open:

http://<device-ip>:2324

Replace <device-ip> with the tablet's actual LAN address. If you changed the port in Kiosk Satellite, replace 2324 as well. Do not enter the Localtonet client device's address here. The HTTP target is the tablet running the embedded Kiosk Satellite service.

Confirm that the login page appears, sign in with the Remote Admin password, and inspect a low-risk function such as device information, the current screen image, or recent logs. Reload the page once to confirm that access is stable rather than the result of a stale browser response.

Check the local health endpoint deliberately

Open the following local address in a private browser context or use an appropriate HTTP inspection tool:

http://<device-ip>:2324/api/health

The project documents this endpoint as unauthenticated. If it returns health data without a login, that behavior is expected. This local test also demonstrates what will become publicly reachable if the root Kiosk Satellite origin is published through an unrestricted HTTP tunnel.

Understand the administration surface and token behavior

Publishing the Remote Admin root origin publishes every path served by that origin, not only the visual login page. This includes the REST namespace, WebSocket endpoint, and unauthenticated health endpoint. Authentication still protects the documented administration functions that require it, but the health endpoint is intentionally an exception.

What the unauthenticated health endpoint reveals

The documented health response can include device identity, addresses, battery information, screen state, RAM, storage, CPU usage and temperature, application uptime, and network uptime. Battery information can be null on a device without a battery, and network uptime is null while offline. Although this endpoint is read-only, publishing it creates public metadata exposure.

Seven-day and long-lived API tokens

A successful POST /api/login returns an HMAC-signed, stateless bearer token. The documented default token lifetime is seven days, and the persisted signing secret allows a session to survive an application or kiosk restart. Automations can request a different lifetime with ttl_days. The project clamps that requested lifetime to a maximum of 3,650 days, or ten years.

The WebSocket authenticates by receiving its token through the token query parameter. Avoid placing authenticated WebSocket URLs in logs, screenshots, analytics systems, shared browser histories, or support messages because the query string contains the credential.

Backups contain secrets

The full backup endpoint exports every setting, including secrets, together with the page's local storage. The documented restore behavior can also adopt the original device identity. When restoring the same kiosk, that identity behavior may be intentional. When provisioning a separate device from an existing export, consult the API documentation for the adoptIdentity and importLocalStorage controls so two devices do not unintentionally share identity-related configuration.

Configure the Localtonet HTTP tunnel

Localtonet exposes the verified HTTP service without requiring inbound router port forwarding, firewall changes, a public IP address, or VPN setup. Our client initiates the connection to a Localtonet relay. The selected client must remain connected, and the tunnel must remain started, for the public address to work.

Use the current Localtonet HTTP tunnel documentation for the current client and dashboard interface. The documented workflow is to install and run the Localtonet client for your operating system, select the device through its device-specific authentication token, select an available server, create the HTTP target, and press Start. Available client packages, servers, regions, and process options can vary, so use the values currently offered by the product instead of copying a server code or installer command from an older article.

Verify the tunnel and public endpoint separately

External verification should prove two different things: first, that the Localtonet tunnel is running; second, that the public address reaches Kiosk Satellite and preserves its authentication behavior. Do not treat the presence of a saved tunnel configuration as proof that either condition is true.

Confirm Localtonet state

1. Verify that the Localtonet client process is running on the selected device.
2. Confirm that the device token appears connected in the current dashboard.
3. Confirm that the intended HTTP tunnel is started rather than merely created.
4. Copy the assigned public HTTPS address without adding the local port.

Test from outside the kiosk LAN

Use a device on a genuinely separate network, such as a mobile connection with Wi-Fi disabled. Open the assigned public HTTPS address in a private browsing window. The Kiosk Satellite login interface should appear. Authenticate using the Remote Admin password and confirm a low-risk function such as device information or the current screenshot.

Reload the public page and observe whether live controls or state continue to update. Remote Admin uses /api/ws for live state, events, and log tailing. A page that loads but never updates can indicate a WebSocket-specific problem rather than a complete HTTP tunnel failure.

Verify the public metadata decision

While still on the external network, append /api/health to the public origin:

https://<assigned-public-host>/api/health

Do not include a real private hostname in documentation or screenshots. If health information is returned without authentication, that confirms the documented behavior and the metadata exposure created by publishing the origin. If that exposure is unacceptable, stop the tunnel while you reconsider the architecture or access policy.

Test stopping and restarting

Stop the tunnel from the dashboard and verify that the public address no longer reaches the kiosk. Start it again and confirm that access returns. This controlled test verifies the operational switch administrators will use during maintenance or an incident.

Troubleshoot each layer independently

Kiosk Satellite server does not start

Confirm that the application is running, Remote Administration is enabled, and a Remote Admin password is set. The current project documentation requires both remote.enabled and remote.password. Check the configured port rather than assuming it is still 2324. Review on-device Kiosk Satellite logs where available, and restart the application in a controlled manner after saving necessary work.

If the Home Assistant dashboard also fails on the tablet, solve the application, credential, or Home Assistant reachability problem first. The embedded Remote Admin service and the dashboard are related parts of the same deployment, but a tunnel cannot correct an invalid Home Assistant configuration.

The server works on the tablet but not from another LAN device

Recheck the tablet's current IP address and verify that both devices are on networks allowed to communicate. Guest Wi-Fi and some wireless networks isolate clients from one another. Separate VLANs may require an explicit route and permitted firewall policy. Confirm that you are connecting to the tablet rather than the Localtonet client machine.

If the address changed after a reboot or lease renewal, update your test URL. A stable DHCP reservation or another network-managed assignment can reduce these changes, but the exact method belongs to your router or network platform and is outside Kiosk Satellite and Localtonet configuration.

Local access works from one machine but not the Localtonet client device

Perform the local browser test from the exact machine running our client. A successful test from a laptop does not prove that a server, container host, or machine on another VLAN has the same route. Check the client's host firewall, network interface, routing table, DNS assumptions if a hostname is used, and access policy between that host and the tablet.

The Localtonet device is disconnected

Confirm that the Localtonet client process is running and authenticated with the intended device-specific token. Check whether the host is online and can make outbound connections. If the wrong token was used, the dashboard may show a different device than the one expected. Never post the token while requesting support.

The tunnel exists but the public address is unavailable

Check whether the tunnel was actually started. Creating a tunnel does not start it. Confirm that the selected client remains connected, the tunnel shows a running state, and you are using the public address assigned to that tunnel. If the tablet's IP address or Remote Admin port changed, edit the local target to match the currently verified values.

The public page returns a gateway or target error

Return to the Localtonet client machine and open the tablet's local Remote Admin address. If that local request now fails, the problem is between the client machine and the tablet. If it succeeds, compare the working address and port with the HTTP target entered in the tunnel. Look for a mistyped address, old DHCP lease, incorrect port, or selection of the wrong tunnel or client.

The login page appears but authentication fails

This result proves that public HTTP routing reaches Kiosk Satellite. Focus on application authentication rather than the tunnel target. Confirm the current Remote Admin password locally, watch for keyboard-layout or autofill mistakes, and remember that failed login attempts are rate-limited with exponential backoff per client IP. Wait for the backoff rather than repeatedly retrying.

Changing the password does not invalidate existing stateless API tokens. Conversely, an old password will no longer create a new token after the password changes. Distinguish a browser password failure from an automation that is still presenting a previously issued bearer token.

The page loads but live state or logs do not update

The initial page and REST requests can succeed even if the WebSocket at /api/ws is not functioning correctly. Reload the page, sign in again, and inspect browser diagnostics for a failed WebSocket connection without sharing token-bearing URLs. Test locally and publicly to determine whether the failure appears before or after the tunnel.

Because WebSocket authentication uses a token query parameter, expired or malformed tokens can affect live functionality. A newly authenticated browser session can help distinguish token expiration from network transport. Do not paste the WebSocket URL into public troubleshooting material because its query string can contain the token.

The public root works but /api/health behaves differently

Verify the exact path and ensure no browser extension, cache, or unrelated intermediary is changing the request. The project documents GET /api/health as the one unauthenticated API endpoint. If you introduce additional access-control infrastructure outside the scope of this tutorial, its policy can alter the observed result.

Routine operation, updates, backups, and incident response

Monitor the tablet address and target port

A changing tablet LAN address is one of the most common operational causes of target failure. After a tablet reboot, Wi-Fi change, DHCP renewal, or network migration, verify the address from an authorized source and repeat the local browser test from the Localtonet client machine. Update the tunnel target when the address or Remote Admin port changes.

Keep the required processes available

Remote access depends on Kiosk Satellite, the tablet's network connection, the machine running our client, the Localtonet client process, its outbound relay connection, and the running tunnel. If continuous access is required, operate the client on a suitably managed device and account for operating-system updates, sleep behavior, power loss, and network maintenance. This article does not claim an uptime guarantee for any component.

Stop or delete access deliberately

Use Stop when remote administration should be temporarily unavailable but the configuration will be reused. Delete the tunnel when the public mapping is no longer required. Stopping or deleting the tunnel removes that Localtonet access path, but it does not disable Kiosk Satellite's LAN server. Disable Remote Administration on the tablet as well if local administration should also stop.

Update Kiosk Satellite carefully

Review the official releases page before updating and record the version being replaced. Read the release notes for relevant fixes and behavior changes, then schedule the update for a period when local recovery is possible. After updating, verify the dashboard on the tablet, confirm the Remote Admin settings and port, repeat the LAN test, and finally retest the public tunnel.

Do not assume that every release preserves every setting or operational behavior without review. Keep a protected backup when appropriate, but remember that the full backup includes secrets and local storage. An update package and a configuration backup solve different recovery problems and should not be treated as interchangeable.

Back up and restore safely

Store exported configuration in an access-controlled location with a retention policy appropriate for credentials. Do not upload an unreviewed backup to a public repository or issue tracker. When replacing the original tablet, identity adoption may be desired. When cloning a separate tablet, review the documented import controls so it retains its own identity and optional Voice Satellite selection.

Respond to a Remote Admin password exposure

Change the Remote Admin password, review available logs and recent administrative behavior, and consider stopping the Localtonet tunnel during investigation. Remember that the password change does not revoke bearer tokens already issued. The project evidence supplied for this article does not document an individual token-revocation list, so do not claim that a password reset alone ends every existing session.

Respond to an API token exposure

Treat the incident according to the token's possible lifetime. A normal token can remain valid for seven days, while a requested long-lived token can be valid for as many as 3,650 days. Stop the public tunnel if immediate containment is necessary, inspect the device and logs, protect or replace affected configuration, and consult current Kiosk Satellite documentation for any newly available revocation or signing-secret reset procedure before taking destructive action.

Respond to a Localtonet device-token exposure

Treat the device token as compromised authentication material. Stop affected tunnels where possible, remove the token from public locations, and use the current Localtonet dashboard and support process to replace or retire the affected device credential. Do not confuse this response with changing the Kiosk Satellite password. The two credentials protect different layers.

Respond to a backup exposure

Assume that settings, secrets, and page local storage contained in the backup may be compromised. Identify the credentials represented in that specific export and rotate them through their owning systems. Depending on the configuration, this can involve Kiosk Satellite, Home Assistant, or optional integrations. Avoid asserting that deleting the backup from one location invalidates credentials already copied elsewhere.

Security checklist for an exposed kiosk

A public HTTPS address protects transport to the Localtonet tunnel edge, but it does not make a weak application password safe or reduce the authority of a stolen bearer token. Apply least privilege, minimize exposure duration, and avoid collecting credentials in screenshots or diagnostic bundles.

Frequently asked questions