Set Up Kiosk Satellite Remote Access with Localtonet

How Kiosk Satellite remote access works

Kiosk Satellite is an open-source Home Assistant kiosk application. Its Remote Administration service exposes a browser interface at /, a REST namespace under /api/, and a WebSocket at /api/ws for live state, events, and log tailing. The documented default HTTP port is 2324, but administrators can change it.

Localtonet does not install or configure that service. Our client runs on a trusted device that can reach the tablet and establishes an outbound connection to a Localtonet relay. An HTTP tunnel provides a public HTTPS address for the local target. The client device and the target tablet can be different machines; what matters is that the selected client can reach the configured IP address and port.

The transport boundary matters

This walkthrough targets http://<tablet-ip>:2324, not a native HTTPS listener. The browser uses HTTPS to reach the public Localtonet address, but the client-to-tablet connection remains HTTP. Credentials and application traffic on that last hop therefore need a trusted local network. A browser padlock does not establish end-to-end HTTPS to the tablet.

The project's current Remote Management documentation includes native HTTPS and certificate guidance. Its documented navigation behavior distinguishes imported certificates from generated certificates and accounts for certificate DNS names. However, the complete certificate installation procedure and its release compatibility are not established here. This guide does not invent a certificate format, HTTPS port, Localtonet upstream TLS option, or certificate-validation bypass. If your policy requires HTTPS on the LAN hop, stop at that requirement and validate a supported configuration before proceeding.

Prerequisites and version scope

Prepare an Android tablet, a reachable Home Assistant instance, a trusted machine for our client, and authorized access to the relevant network and accounts. The previously documented Android baseline is Android 7.0 or newer, but verify the requirements of the APK you actually select. Manufacturer-specific power management, WebView behavior, permissions, and kiosk restrictions can affect compatibility independently of the Android version.

This guide describes the HTTP deployment pattern and the behavior documented in the project's current Remote Management documentation. It is not a version-certified walkthrough for release 2026.8.79. That release exists, but newer main-branch documentation cannot establish which later features were present in it. Choose one release from the official releases page, record its version, and use documentation or source from that same tag when confirming security-sensitive behavior.

Prepare the Home Assistant connection

Before installing the kiosk, open the intended Home Assistant URL from the tablet's network. Confirm the hostname resolves, the server responds, and any HTTPS certificate is accepted normally. Do not configure a URL that works only from an administrator's laptop or only through a separate VPN that the tablet does not use.

Have an authorized Home Assistant account and access to the intended dashboard. The exact Kiosk Satellite credential requirement must be checked for the selected release: this guide cannot establish whether that wizard requires an interactive login, a long-lived access token, or another supported flow. If it requests a Home Assistant long-lived token, obtain it through Home Assistant's account controls and keep it in a credential store. Never substitute the Localtonet device token or the kiosk's Remote Admin password.

Prepare the client host and network

Choose a supported client host that can remain available for the intended maintenance window. Confirm the currently offered Localtonet operating-system packages before choosing the host. A desktop or managed server on a permitted route to the tablet is suitable in principle; do not assume that the client must run on Android.

Record the tablet address, Remote Admin port, selected client host, application version, and recovery contact. A DHCP reservation can help keep the tablet address stable. It does not replace application authentication. Ensure that guest Wi-Fi isolation, VLAN policy, or endpoint firewall rules permit the required client-to-tablet connection without weakening unrelated network controls.

Install and prepare Kiosk Satellite

Install the official Android package

1. Select a release from the official project releases page and read its requirements and release notes.
2. Download the APK attached to that release directly on the tablet, or transfer that official file through an approved channel.
3. Open the APK. If Android requests permission to install from that source, grant it only to the browser or file manager being used.
4. Complete Android's installation prompts and launch Kiosk Satellite.
5. Remove the source's installation permission afterward if required by your device-management policy.

Do not download a similarly named APK from an unrelated mirror. Keep the release identifier with your deployment record so a later failure can be correlated with the exact application build. Installing an older release solely to match a screenshot is not a substitute for reviewing security and compatibility changes.

Complete the setup wizard

The application has been documented with a five-step guided setup, but the exact page order and credential fields have not been verified for a fixed release here. Prepare the following inputs and apply them to the corresponding prompts in your installed version:

• Home Assistant address: the URL already tested from the tablet's network.
• Home Assistant authorization: the credential type explicitly requested by that version, associated with an account authorized for the intended dashboard.
• Dashboard selection: the view the tablet should display during normal kiosk operation.
• Optional integration choices: enable only the integrations you plan to configure and maintain, including optional voice functionality where available.
• Android permissions: grant the permissions needed for those selected capabilities rather than every optional permission.
• Remote Admin password: set a unique password through the optional wizard field where available, or configure it afterward in settings.

After setup, confirm that the intended dashboard renders and remains usable after a reload. Test the intended local exit and recovery method before applying strong kiosk restrictions. The project's kiosk protection documentation is useful context, but match its instructions to the installed version. A normal Android application cannot be assumed to block every physical or system-level escape route.

Enable and verify Remote Administration locally

The current Remote Management API documentation states that the server starts only when remote.enabled is on and remote.password is set. On the device, swipe from the left edge, open Settings → Device → Remote Administration, enable the service, and set a unique password. Confirm the actual port rather than assume it remains 2324.

Find the tablet's current LAN address in Android network information or your authorized network-management interface. From the proposed Localtonet client host, open:

http://<tablet-ip>:2324

Replace the placeholder and port with the verified values. The target is the tablet, not the Home Assistant server and not automatically the machine running our client. A loopback address such as 127.0.0.1 would refer to the client host itself unless the service actually runs there.

Test both logged-out and authenticated behavior

Use a private browsing window with no existing kiosk session. Confirm that administration requires login, then sign in and inspect a low-risk function such as device information, a screen image, or recent logs where offered. Reload the page and confirm that live state still works. Avoid changing network settings, restarting the tablet, or importing configuration during the first connectivity test.

If /api/health is present in your version, inspect it in a separate logged-out context:

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

Record the response status and the actual fields returned. This guide does not establish a release-matched health-response schema or guarantee that it is identical across builds. Any response available without authentication may become visible publicly when you expose the origin.

Review authentication and public exposure

Publishing an application's origin is broader than publishing its login page. Paths used for login, API calls, live connections, static assets, and health checks can all be reachable through the same tunnel. Application authentication remains responsible for restricting administrative actions. A public HTTPS URL is transport protection, not an additional application login.

Do not describe health as the only endpoint that accepts requests without a bearer token. The login endpoint necessarily receives requests from clients that have not yet obtained one. That is different from permitting unauthenticated access to administrative data or commands.

Token lifetime and revocation need version-specific confirmation

This guide does not assert a seven-day default, a ten-year maximum, a specific signing format, or password-change revocation behavior. Those claims require complete documentation or source for the selected build. Before enabling automation, determine the actual token expiry, supported lifetime controls, session persistence, and available revocation mechanism.

Do not assume either that changing a password revokes every session or that existing sessions necessarily survive it. In an incident, contain access first and use the verified procedure for that version. If browser diagnostics show a credential in a WebSocket query string, redact the entire query before sharing logs or screenshots.

Backups and restore controls

Treat configuration exports as sensitive until their contents have been inspected securely. They may contain credentials, identifiers, or browser storage depending on the version and export type. Do not assume that an export is safe to attach to a public issue.

The exact inclusion of secrets and local storage, and the availability or semantics of identity-adoption controls, are not verified here. Before cloning a kiosk, inspect the version's documented restore options and test on a non-production device. Verify the resulting device identity, Home Assistant associations, credentials, and integration settings instead of relying on an unconfirmed flag name.

Prepare the client and configure the HTTP tunnel

With Localtonet, the client initiates the relay connection, so you do not need an inbound router port-forwarding rule, a public IP address, or VPN setup. Existing network authorization still applies: the client needs permitted outbound connectivity and a permitted route to the tablet.

Client installation and startup boundary

Use the operating-system package provided by our current dashboard or HTTP tunnel documentation. Install and launch it on the verified client host, authenticate it with the device-specific token assigned to that host, and confirm that the intended device appears connected in the dashboard.

An exact supported installer filename, extraction procedure, launch command, token-entry screen, and automatic-start method are not established here. We therefore do not provide a guessed shell command or claim that installation automatically creates a background service. Keep the client running during testing. Before relying on unattended access, verify the supported startup method for your installed client version and test it after a host restart.

The following sequence is our verified general tunnel lifecycle, not a claim that the current HTTP documentation has exactly this many screens or numbered steps. The exact HTTP-page step count must be checked against the live documentation before a release-specific installation recipe is published.

Configure Admin URL and understand kiosk switching

The current project documentation describes an Admin URL setting under Settings → Device → Remote Administration. For reverse-proxy access, it accepts an origin such as https://kiosk.example.com, optionally with a port and without a path. Where supported by your release, set it to the assigned public Localtonet origin after that address has been tested.

This setting advertises where the administration interface should open. It does not create a tunnel, configure DNS, change the local listener to HTTPS, or add authentication. If your public address changes, review the Admin URL and any bookmarks that depend on it. The setting is per device and does not synchronize from a fleet leader.

A switcher entry is not a network route

The documented kiosk switcher lists discovered kiosks and saved fleet members. Selecting another kiosk opens that kiosk's administration interface in the same browser tab. The chosen endpoint must therefore be reachable from the administrator's browser, not merely from the first kiosk.

If the selected entry points to a private LAN address, an off-site browser generally cannot reach it. Publishing one kiosk does not automatically publish the others. Each kiosk intended for off-site switching needs an independently reachable administration endpoint and suitable access controls. A different password may also require a separate login.

Discovery uses mDNS on the local network. Multicast does not cross VLANs by itself, and a public HTTP tunnel does not transport LAN discovery. Saved fleet members can remain listed without multicast, but listing alone still does not make them reachable.

Certificates and fleet communication remain separate

For native HTTPS with an imported certificate, the current project documentation says the switcher can prefer a covered DNS name, excluding wildcard and .local names for that selection. That name must resolve correctly from the browser's network. Admin URL takes precedence over the certificate-derived name and IP address.

Fleet synchronization and the intercom continue to use IP addresses rather than Admin URL. Do not replace fleet-network planning with public browser URLs. Validate local routing between participating kiosks and keep fleet-version compatibility checks separate from testing browser access.

Verify public access from a separate network

Use a device on a genuinely different network, such as a mobile connection with Wi-Fi disabled. Open the assigned HTTPS address in a private browser window without appending the tablet's local port.

1. Check the origin: confirm you reached the expected kiosk and that the browser reports no certificate warning.
2. Check logged-out access: verify that administration is not available before authentication.
3. Sign in: use the kiosk's Remote Admin credential, not the Localtonet device token.
4. Perform a low-risk read: inspect device information or another available non-destructive function.
5. Check live behavior: reload and observe whether state or log updates continue.
6. Inspect exposure: test any health endpoint in a separate logged-out context and review its actual response.
7. Test navigation: if using Admin URL or the kiosk switcher, verify every intended destination independently.
8. Test containment: stop the tunnel, confirm that fresh public requests no longer reach the kiosk, then restart only if continued access is required.

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

A rendered page already in browser memory can remain visible after stopping a tunnel. Use a fresh request or reload when checking availability. If health data remains accessible without login while the tunnel runs, assess the actual metadata exposure rather than assume read-only means harmless.

Troubleshoot one layer at a time

The local server does not respond

Check that Kiosk Satellite is running, Remote Administration is enabled, a password is set, and the port matches your test URL. Recheck the tablet address after Wi-Fi changes or restarts. Inspect on-device logs where available. If you enabled native HTTPS, an HTTP test against that listener may no longer match its configuration; do not guess a replacement port.

One LAN device connects, but the client host cannot

Compare their network segments and permitted routes. Guest Wi-Fi isolation, VLAN rules, host firewalls, or container networking can produce different results. Use the tablet IP for the initial test to separate routing from hostname resolution. A working .local name on one operating system does not guarantee that it resolves on another.

The client is disconnected or the tunnel is unavailable

Confirm the client process is running and authenticated as the intended device. Check the host's power, sleep state, and authorized outbound connectivity. Then confirm the specific tunnel is started. The public route requires both a connected client and a running tunnel.

The public address returns a target or gateway error

Repeat the local HTTP test from the client host immediately. If it fails, investigate the LAN or kiosk. If it succeeds, compare the working IP and port with the tunnel target and verify that the correct client was selected. An old DHCP address, wrong port, or accidentally targeted Home Assistant server can explain the mismatch.

The login page works, but login fails

Routing is at least reaching the application. Test the current Remote Admin password locally, check keyboard layout and autofill, and avoid repeated automated attempts. Rate-limit and lockout details must be confirmed for your version rather than assumed. Keep password failure distinct from an existing session or automation presenting an older token.

The page loads, but live state does not update

Compare local and public behavior for /api/ws. Inspect browser diagnostics for connection failures, incorrect origins, redirects, or authentication errors. An HTTPS page attempting an insecure WebSocket can encounter browser mixed-content restrictions. Do not work around this by disabling browser security, and redact token-bearing URLs before sharing diagnostics.

The switcher opens an unreachable kiosk

Inspect the selected destination. If it is a private address, the browser may have no route to it. Verify that kiosk's own public endpoint and Admin URL where supported. If it uses a certificate DNS name, check resolution and certificate coverage from the remote network. Fleet membership is not evidence of internet reachability.

Operate, update, and recover safely

Keep a short operational record with the application and client versions, tablet address, port, public origin, Admin URL, maintenance owner, and last successful local and external tests. Store credentials separately. Account for operating-system updates, device sleep, Wi-Fi changes, power loss, and DHCP changes when deciding whether the deployment is suitable for unattended access.

Updates and backups

Review release notes, keep a protected backup where supported, and schedule changes when local recovery is possible. After updating, verify the on-device dashboard, local Remote Admin access, authentication, public access, live updates, and switcher behavior in that order. Recheck security-sensitive assumptions when changing versions.

Before a restore, determine whether the operation replaces or merges settings and whether it affects identity or stored authorization. Do not import an unreviewed production export into another tablet. Test recovery separately from cloning, since preserving the original device's identity and creating a distinct new device are different goals.

Credential incidents

If a kiosk password or API token may be exposed, stop public access during investigation, review available logs, and use the installed version's documented credential and session-revocation procedures. Stopping the tunnel contains that public route but does not disable LAN access or invalidate application credentials.

If a Localtonet device token is exposed, use the current dashboard and support process to replace or retire the affected credential. If a backup is exposed, inspect which credentials it actually contains and rotate them through their owning systems. Removing a public file does not invalidate copies already downloaded.

Publication and deployment checks

The retained illustrations describe the intended topology, not proof of a tested installation. Before publication, verify that each image asset loads and accurately represents the HTTP transport boundary, and check linked pages for availability and current relevance. No broken link or asset is established here. Before deployment, complete the unresolved installer, wizard, certificate, and release-specific security checks described above.

Frequently asked questions