Choose the right FaserF channel, verify the selected app locally, and publish its web interface only when it is ready
FaserF’s Home Assistant Apps repository contains web servers, dashboards, productivity tools, network utilities, and other self-hosted applications for Supervisor-managed Home Assistant installations. This guide explains how to add the stable or edge repository, evaluate the current catalog, install and configure an app, and verify its exact local endpoint. It then provides a self-contained Debian or Ubuntu installation path for the Localtonet client and explains how to publish a verified HTTP application without inbound router port forwarding or a public IP address. Because architecture support, ingress availability, host ports, credentials, status, and configuration vary by app and version, every exposure decision must be based on the selected app’s current documentation rather than catalog-wide assumptions.
📋 What's in this guide
What FaserF’s Home Assistant Apps repository provides
A Home Assistant app repository is a catalog that Home Assistant Supervisor can read. A repository may contain one or many apps, formerly called add-ons, with each app stored as a separate entry. The entry carries its own metadata, documentation, configuration schema, supported architectures, startup behavior, network mappings, and container definition. Adding a repository does not install every application in it. It makes the available entries visible in the Add-on Store so that you can inspect and install them individually.
FaserF’s project retains the repository name hassio-addons, while its current documentation describes the packages as Home Assistant Apps. Both names therefore appear in URLs, interfaces, project files, and community discussions. In this guide, “app” means a Supervisor-managed package and “repository” means the catalog from which that package is offered.
Start with the FaserF Home Assistant Apps repository. Its README contains the maintainer’s current channel instructions, status model, support warning, and repository URLs. The separate current FaserF app catalog provides searchable filters for status, category, ingress support, and architecture. Use those live pages when choosing an app because the catalog can add, remove, promote, deprecate, or rename entries after this article is published.
At the time of the supplied 2026 catalog review, examples included Apache2 variants, NGINX, Wiki.js, WordPress, Planka, Tiny Tiny RSS, ShieldDNS, ShieldFile, Netboot.xyz, OpenSSL, messaging tools, dashboards, and development utilities. These examples do not share one maturity level, architecture list, exposure method, or authentication model. Their names and statuses must be rechecked against the live catalog before installation. A current catalog entry is evidence that an app is listed, not evidence that it is appropriate for your hardware or safe to expose publicly.
amd64 or aarch64. Confirm the selected entry against your host architecture before installation.
The documented repository workflow requires a Home Assistant installation with Supervisor and the Add-on Store. Home Assistant Container and Home Assistant Core do not automatically provide this Supervisor-managed app workflow. Do not substitute arbitrary Docker commands unless the selected upstream project separately documents and supports a standalone deployment.
Home Assistant’s app repository documentation explains the general repository model. Its app configuration documentation explains how each app declares properties such as its supported architectures, web interface, startup behavior, persistent data, ingress settings, and network ports. These are useful for understanding why there cannot be one universal configuration or port for all FaserF apps.
The FaserF maintainer states that these apps are primarily maintained for personal use and that bug fixes, feature requests, or continued support cannot be guaranteed. The repository also reports testing on amd64, but that catalog-wide statement does not prove identical behavior across every architecture or app. Before depending on an entry for an important workflow, review its current documentation, release history, issue activity, storage model, and recovery requirements.
Stable, edge, and unsupported status explained
Repository channel and app status are related, but they are not identical concepts. The stable repository channel contains stable releases and excludes in-development apps. It uses pre-built Docker images from official releases and is the maintainer’s recommended path for general use.
The edge repository includes stable apps plus in-development entries and bleeding-edge builds. According to the maintainer’s current instructions, edge apps are built locally on the Home Assistant device from Dockerfile source instead of using the stable channel’s pre-built release images. Installation can therefore take longer and consume more processor, memory, storage, and network resources while the build runs.
The app catalog separately uses status labels. In the current status model, a check mark identifies a stable app with a version at or above 1.0.0, a warning symbol identifies a functional beta below 1.0.0 that remains in development, and a cross identifies an unsupported app that is no longer maintained. These labels describe current project status, not a security certification, compatibility guarantee, or promise of future maintenance.
| Channel or status | Current documented meaning | Installation behavior | Appropriate use |
|---|---|---|---|
| Stable channel | Stable releases only | Uses pre-built official release images | General deployments where the required app is available |
| Edge channel | Stable and in-development apps | Builds locally from Dockerfile source | Testing or intentionally using an app or change not yet in stable |
| Beta app | Functional but still in development, currently represented by a version below 1.0.0 | Behavior and configuration may change as development continues | Users prepared to test, troubleshoot, and monitor updates closely |
| Unsupported app | Archived, deprecated, or no longer maintained | No active maintenance level should be assumed | Existing deployments with a recovery or migration plan, not a default new installation |
Choose edge only when you need an in-development app or intentionally want its latest source. It can contain experimental or rapidly changing software, and its local build process is slower than installing a pre-built stable image. If the required app is available in stable, begin with stable unless the app’s documentation gives you a specific reason not to.
Prerequisites and decisions to make first
Confirm that your Home Assistant installation exposes the Supervisor-managed Add-on Store. The current FaserF instructions refer to Settings → Add-ons → Add-on Store, but interface labels and menu placement can change between Home Assistant releases. The essential requirement is access to Supervisor repository management. If you cannot find an Add-ons area or repository control, identify your installation type before continuing.
You need Home Assistant permissions sufficient to add a custom repository and install apps. Create a current backup before installing a new application, especially if it writes persistent content, initializes a database, maps Home Assistant directories, or is marked beta. A Home Assistant backup is important, but database-backed and content-heavy applications may also document separate export or database backup procedures. Test the recovery method that applies to the selected app rather than assuming every file is covered in the same way.
Check the selected app, not just the repository
Open the app’s current catalog entry and documentation before installing it. Confirm its status, supported architecture, storage requirements, required options, dependencies, startup behavior, and network model. Architecture support comes from the individual app’s metadata. Home Assistant currently recognizes app architecture declarations including aarch64 and amd64, but a given app may list only one of them.
Also confirm whether the selected app supports Home Assistant ingress, a direct host port, or both. The live catalog offers an ingress filter, but ingress availability remains app-specific and can change. A catalog count or filter is not a promise that every listed web application supports ingress.
Prepare for optional remote access
Keep app installation and public exposure as separate milestones. First make the application healthy inside Home Assistant. Then identify a direct HTTP or HTTPS endpoint that the device running the Localtonet client can reach. If no safe direct endpoint is documented, complete the Home Assistant installation but do not create a tunnel by guessing internal addresses.
Record these values from the selected app’s documentation and Home Assistant network settings:
- The local IP address or hostname reachable from the intended Localtonet client device.
- The effective host port, rather than only the container’s internal port.
- Whether the direct endpoint uses HTTP or HTTPS.
- Any required path following the hostname and port.
- Whether direct access provides its own login or depends on Home Assistant ingress.
- Whether the service listens only on loopback or accepts connections from another LAN device.
- Whether the application requires an external URL, trusted proxy, allowed-host, or forwarded-header setting.
Home Assistant ingress can place an app behind Home Assistant routing and session handling. A direct host port may reach the application independently and may not inherit that protection. Test the exact direct endpoint in a private browser session. If it opens an unprotected dashboard, first-run wizard, or administrative interface, do not publish it until you configure the access controls recommended by that application.
Install the stable or edge repository and select an app
The repository URL determines the channel. Use the stable URL without a fragment for the recommended general-use catalog. The edge workflow uses the same repository with the exact #edge suffix.
| Choice | Repository URL | Use it when |
|---|---|---|
| Stable | https://github.com/FaserF/hassio-addons |
The selected app is available as a stable release and you want the recommended path |
| Edge | https://github.com/FaserF/hassio-addons#edge |
The selected app requires edge or you intentionally need bleeding-edge changes |
| Unsupported | Not recommended as a default installation path | You understand that the selected app is unmaintained and have evaluated maintained alternatives |
Stable repository workflow
The maintainer documents stable as the recommended channel and supplies the stable repository URL. Home Assistant’s repository documentation describes adding a custom repository through the Supervisor store’s repository control. The exact placement of that control can change, so use the current Add-on Store interface rather than assuming an older screenshot is exact.
Open repository management
In your Supervisor-managed Home Assistant installation, open Settings → Add-ons → Add-on Store, then open the store menu and its Repositories control.
Add the stable repository URL
Enter https://github.com/FaserF/hassio-addons and use the interface action that saves or adds the repository.
Select and install one reviewed app
Find the desired entry under FaserF’s Home Assistant Apps, review its current status, architecture, documentation, configuration, and network details, then open it and select Install.
Edge repository workflow
The maintainer provides a more explicit workflow for edge. Follow it closely because the #edge suffix identifies the channel and edge entries are grouped under separate repository labeling.
Open the Home Assistant repository dialog
Navigate to Settings → Add-ons → Add-on Store → three-dot menu → Repositories.
Enter the edge URL
Enter https://github.com/FaserF/hassio-addons#edge exactly, including the fragment suffix, and select Add.
Refresh the Add-on Store
Open the three-dot menu and select Check for updates. Allow Home Assistant time to retrieve and process the edge repository metadata.
Find the app under the edge repository
Locate the app under FaserF’s Home Assistant Apps (Edge), confirm that your system meets its current requirements, and select Install. Expect a local build that can take longer and use more resources than a stable image installation.
Installation success means that Home Assistant has installed the package. It does not prove that the app is configured, started, healthy, authenticated, or reachable. Continue through configuration and local verification before enabling remote access.
Configure and start the selected Home Assistant app
There is no repository-wide configuration shared by every FaserF app. A web server, DNS service, dashboard, feed reader, file-sharing application, and automation utility require different options. Open the installed app’s documentation and configuration interface and follow the schema for that exact app version.
Home Assistant app configuration is app-specific. Its developer documentation explains that persistent data is available under /data and user options are provided to the app through /data/options.json. As a user, you should normally edit those options through Home Assistant’s app interface. Do not modify internal files or copy keys from another app unless the selected app explicitly documents that procedure.
Read the installed version’s documentation
Review required options, first-run behavior, storage locations, dependencies, credential requirements, network settings, and warnings associated with beta or edge builds.
Complete required configuration
Enter only settings documented for the selected app. Use unique credentials where authentication is supported, and do not reuse your Home Assistant administrator password for an unrelated application.
Review ingress and network mappings
Inspect whether the current app version supports ingress and whether it exposes an effective host port. A port mapping with a null or disabled host value does not provide a direct LAN endpoint.
Save and start the app
Save the configuration and select Start. If the app provides a start-at-boot control, enable it only after confirming that startup and recovery work correctly.
Inspect startup logs
Look for completed initialization instead of relying only on a displayed running state. Resolve invalid options, missing dependencies, permission problems, architecture errors, database failures, and port conflicts before proceeding.
Some web applications present a browser-based first-run wizard. Complete that process locally. Create the administrator account, replace documented default credentials, set the application’s canonical URL if required, and restart it to confirm that the secured configuration persists.
Optional Webserver App integration
Users of supported Apache2 and NGINX variants can separately install FaserF’s Webserver App integration for Home Assistant. It is a dedicated integration that discovers supported local webserver apps through Home Assistant Supervisor and can expose operational status, selected performance metrics, error and warning log information, certificate expiration data, diagnostics, and restart controls.
The integration currently documents support for specific Apache2, Apache2 Minimal, Apache2 Minimal with MariaDB, and NGINX slugs, including corresponding edge variants. It is not the web server app itself, it does not install the FaserF repository, and it is not required for Localtonet tunneling. Check its current supported-app table before installing it because support is based on explicit internal slugs rather than every web-related entry in the catalog.
Verify the app locally before exposing it
Verify the application in layers. First confirm that it remains started. Next inspect the logs for completed initialization. Then open it through Home Assistant ingress if the selected app supports ingress. Finally, if you plan to create a Localtonet HTTP tunnel, test the exact direct endpoint from the same device that will run our client, or from another device with equivalent network access.
How to identify the correct local endpoint
Start with the selected app’s documentation and Home Assistant network settings. Home Assistant app metadata can define a webui template containing placeholders for the host and effective port. It can also map an internal container port to a host port. Use the URL presented by Home Assistant and the effective network mapping rather than deriving an address from container internals.
The target address must be meaningful from the Localtonet client device. If our client runs on another LAN computer, 127.0.0.1 on that computer points back to the Localtonet client computer, not to Home Assistant. Use the Home Assistant host’s LAN address and effective host port when that is the documented, reachable endpoint.
If the Localtonet client runs on the same system that exposes the app’s host port, a local address may be suitable, but it still needs to be tested from that environment. Do not confuse the port inside the app container with the host port that Home Assistant exposes. A mapping can use a different effective port or be disabled entirely.
Apache2, NGINX, Wiki.js, WordPress, Planka, Tiny Tiny RSS, and the other repository entries do not share one guaranteed hostname, port, path, protocol, or authentication model. Use the selected app’s current documentation and effective Home Assistant network configuration. A generic port copied from another app can target the wrong service or expose something unintended.
Expose a verified HTTP app with Localtonet
Once the application works at a direct local HTTP or HTTPS endpoint, you can make that service remotely reachable with Localtonet. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
The client can run on the same supported device as the local service or on another always-on device that can reach it over the LAN. The important requirement is that the client device can open the exact local IP address and port you intend to configure.
Supported client deployment choices
The current Localtonet getting-started documentation provides downloads for Windows, Linux, macOS, Docker, and Android. Linux downloads include x64, ARM, ARM64, and MUSL variants. Installable DEB and RPM packages are also documented for x64 and ARM64 systems that meet their requirements.
For a small always-on computer on the same network as Home Assistant, a Linux system service is a practical documented deployment. The package workflow currently requires systemd 247 or newer and OpenSSL 3, such as Debian 12, Ubuntu 22.04 or newer, or RHEL 9. The steps below use the documented Debian or Ubuntu x64 package path. If your device uses a different operating system or architecture, select the matching supported download and follow the corresponding current documentation rather than substituting the x64 package.
Install the Localtonet client on Debian or Ubuntu x64
Download the current localtonet-linux-x64.deb package from our documentation to the Linux device that can reach the Home Assistant app. Open a terminal in the directory containing the downloaded package, then install it:
sudo apt install ./localtonet-linux-x64.deb
Next, edit /etc/localtonet/auth-token as root and replace the package’s placeholder value with your own device-specific Localtonet authentication token on a single line. Do not paste that token into a command shown in shell history, an issue report, a screenshot, or public documentation.
Protect the token file and validate the client configuration:
sudo chmod 600 /etc/localtonet/auth-token
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-configOnly after the configuration check succeeds, enable and start the normal Localtonet service:
sudo systemctl enable --now localtonet.service
sudo journalctl -u localtonet.serviceReview the service journal for startup or authentication errors. Then confirm in the Localtonet dashboard that the intended device token is shown as connected. The operating system service running, the device connecting to our platform, a tunnel configuration existing, and that tunnel being started are separate states. A successful systemd start alone does not prove that the selected device is connected or that any tunnel is active.
A Localtonet authentication token identifies the client device that runs the tunnel. Keep it out of public screenshots, logs, source repositories, shell examples, and shared messages. The documented file permission command limits access to the token file, but you must also control administrative access to the Linux device.
Create and start the HTTP tunnel
Use an HTTP/s tunnel for a browser-based application. TCP, UDP, and combined UDP/TCP tunnels are intended for other protocol requirements and should not be selected merely because the application runs in a container. For the current product workflow and field definitions, keep the Localtonet HTTP tunnel documentation available while configuring the tunnel.
Confirm the client device is connected
Verify in the Localtonet dashboard that the intended device token is connected. If it is disconnected, inspect the Linux service journal, authentication file, network access, and configuration check before creating the tunnel.
Select an available relay server
Choose a server or region currently offered in your dashboard. Available values can vary by plan, client version, region, or deployment, so use the live product choices rather than a hardcoded server code from another tutorial.
Create an HTTP/s tunnel
Create an HTTP tunnel and select the connected device that can reach the Home Assistant app. Choose the available process type appropriate to your setup, such as Random Sub Domain, Custom Sub Domain, or Custom Domain. These process types serve the same target content at a public HTTPS address.
Enter the verified local IP address and port
Use the endpoint you already tested from the client device. Do not substitute an internal container address, an ingress-only route, or a loopback address that resolves on a different machine.
Start the tunnel explicitly
Creating the tunnel saves its configuration but does not make it active. Select Start. The selected client must remain connected and the tunnel must remain running for the public address to work.
Verify the public application workflow
Open the assigned public URL in a private browser session. Confirm the expected login, redirects, static assets, application functions, and logout behavior. Then repeat the test from a separate connection such as a mobile network.
First, the device running our client must be connected. Second, the HTTP tunnel must exist and point to the correct local target. Third, the tunnel must be explicitly started. Creating a tunnel does not connect an offline client, and connecting a client does not automatically start a saved tunnel.
Require strong application authentication, remove default credentials, expose only the intended service, apply least privilege, and use app-supported restrictions where appropriate. Do not publish a first-run setup page, an unsupported app, or a direct endpoint that is protected only when accessed through Home Assistant ingress.
Handle reverse-proxy behavior carefully
Some applications need an external base URL, trusted-proxy setting, forwarded-header configuration, or allowed-host entry. These options are app-specific and are not established for every FaserF entry. If the public URL causes a redirect loop, rejected hostname, private-address redirect, mixed-content warning, or broken callback, consult the selected app’s current reverse-proxy documentation.
Do not disable hostname validation, authentication, or broad security controls merely to make an error disappear. Stop the tunnel while correcting the local application configuration, retest the direct endpoint, and only then restart public access.
Routine operation, updates, backups, and channel changes
Monitor app updates through Home Assistant and read current release notes before applying them. Keep recoverable backups of Home Assistant and any app-specific data. A database-backed application or content platform may require an export or database procedure in addition to a Home Assistant backup, so test restoration before treating the deployment as recoverable.
Stable and edge updates have different resource profiles. Stable updates normally retrieve pre-built release images. Edge updates are built locally and can take longer or place additional load on the Home Assistant host. Schedule edge updates when temporary CPU, memory, storage, and network use will not disrupt important automations.
Before updating an internet-facing app, stop its Localtonet tunnel. Apply the update locally, inspect the logs, verify the application’s authentication and core functions, and then start the tunnel again. This prevents remote users from reaching an incomplete migration, reset setup wizard, or temporarily unsecured state.
The Home Assistant app and Localtonet tunnel have independent lifecycles. Stopping the app makes its target unavailable even if the tunnel remains configured. Disconnecting the selected Localtonet client makes the tunnel unavailable even if the app remains healthy. Stopping the tunnel removes public access while preserving its configuration, and deleting the tunnel removes that configuration when the service is retired.
Moving between stable and edge
Do not assume that changing or removing a repository URL safely upgrades, downgrades, or migrates an installed app. Edge configuration and stored data may move ahead of stable. Before changing channels, review the selected app’s migration guidance, create a backup, and determine whether its current version and data format support the intended direction.
If both repositories are registered, verify which copy you are viewing before installation or update. Repository labels, app slugs, and version numbers help distinguish stable and edge entries. Do not run two variants against the same data unless the selected app explicitly documents that arrangement as safe.
Troubleshooting installation and remote access
The repository does not appear after adding it
Confirm the exact URL. Stable uses https://github.com/FaserF/hassio-addons, while edge requires https://github.com/FaserF/hassio-addons#edge. For the documented edge workflow, return to the Add-on Store menu and select Check for updates. If Home Assistant reports a repository error, inspect its Supervisor or system logs and verify that the host has working DNS, network access, and system time.
The desired app is missing from stable
In-development apps are excluded from the stable channel. Check the live FaserF catalog and repository README to determine whether the current entry requires edge, has been renamed, has moved, or is now unsupported. Do not assume that a missing app has one particular cause.
An edge installation takes a long time
Edge builds are compiled locally from Dockerfile source instead of being pulled as pre-built stable images. Longer installation time and increased resource use are expected. Check available storage, processor and memory pressure, and build logs before deciding the process has stalled.
The app will not start
Compare every required field with the documentation for the installed version. Inspect the first meaningful log error rather than only the final shutdown message. Possible categories include invalid options, missing credentials, unavailable dependencies, file permissions, database initialization, unsupported architecture, and port conflicts. The exact resolution is app-specific.
Ingress works, but the direct LAN URL does not
The app may support ingress without an enabled host-port mapping. Review its current network settings and documentation. A Localtonet HTTP tunnel needs a local IP address and port reachable by our client. If the app does not document a safe direct endpoint, do not target an internal container address as a workaround.
The Localtonet service does not connect
On the documented Debian or Ubuntu deployment, rerun the configuration check and inspect the service journal:
sudo localtonet --headless --authtoken-file /etc/localtonet/auth-token --check-config
sudo journalctl -u localtonet.serviceConfirm that the authentication token file contains the correct device-specific token on one line and retains restrictive permissions. Also confirm that the Linux device has outbound network access. Do not publish the token when sharing logs.
The device is connected, but the tunnel is offline
Device connectivity and tunnel state are separate. Confirm that the tunnel was created for the intended device and that you selected Start. A connected client can exist with no running tunnels, and a saved tunnel can remain inactive until it is started.
The public URL shows a connection error
Test the configured local IP address and port from the Localtonet client device. If that direct test fails, correct the app’s host-port mapping, bind address, local firewall, or LAN route first. Then confirm that the intended client is connected and the tunnel is running.
The public page redirects to a private address
The application may generate absolute URLs using its local hostname or configured base URL. Look for documented external URL, host-header, trusted-proxy, or forwarded-header settings in that specific app. Do not guess environment variables or disable validation controls.
The public page loads without authentication
Stop the tunnel immediately. Determine whether the direct endpoint has separate authentication from Home Assistant ingress. Complete the application’s security configuration locally, verify it in a private browser session, and only restart the tunnel when the direct endpoint consistently requires appropriate access.
Frequently asked questions
Should I use the stable or edge FaserF repository?
Use stable for general deployments when the required app is available there. Stable contains stable releases and uses pre-built images. Use edge when an in-development app requires it or when you intentionally want bleeding-edge changes and accept local builds, greater installation resource use, and faster-changing software.
Does adding the repository install every FaserF app?
No. Adding the repository makes its catalog visible in the Add-on Store. You then choose and install individual apps. Each app has its own configuration, architecture support, storage, ingress behavior, network mappings, logs, and update lifecycle.
Can I install these apps on Home Assistant Container?
The documented FaserF repository workflow requires Home Assistant Supervisor and the Add-on Store. A standalone Home Assistant Container installation does not provide that workflow by default. This guide does not invent generic Docker commands because there is no universal standalone installation method for every app in the collection.
Are all FaserF apps available on both amd64 and aarch64?
Do not assume so. Architecture support is declared by each app and must be checked in its current metadata or catalog entry. The maintainer’s repository-wide amd64 testing statement does not guarantee that every app supports every architecture.
What port should I enter in Localtonet?
Enter the effective host port for the selected app’s direct web endpoint, as confirmed in its documentation and Home Assistant network configuration. There is no universal FaserF port. Do not use an internal container port unless it is also the verified endpoint reachable from the Localtonet client device.
Can Localtonet expose a Home Assistant ingress-only page?
A Localtonet HTTP tunnel needs a local IP address and port reachable by our client. A Home Assistant ingress route is not automatically a direct app endpoint. If the app has no documented, safely authenticated direct endpoint, do not guess an internal address or port.
Does Localtonet require router port forwarding?
No. Our client establishes an outbound connection to a Localtonet relay server. The configured service can therefore use its assigned public address without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Why is my Localtonet tunnel unavailable even though I created it?
Creating a tunnel does not start it. Confirm that the selected client device is connected, the tunnel targets the correct local IP address and port, and the tunnel was explicitly started. All three conditions are required for normal operation.
Is an edge app safe to expose publicly?
Edge means the software is being built from the development channel. It does not establish that the app is suitable for internet exposure. Evaluate the selected app’s authentication, current documentation, update process, issue status, reverse-proxy behavior, and security model. Keep it private when those controls are unclear.
Will the public app remain available if Home Assistant or the Localtonet client stops?
No. The target Home Assistant app must remain available, the selected Localtonet client must remain connected, and the tunnel must remain running. Stopping the app, disconnecting the client, or stopping the tunnel interrupts the public service.
Publish your verified Home Assistant app with Localtonet
After the selected FaserF app is configured, authenticated, and reachable through a confirmed local HTTP endpoint, install our client on a device that can reach it and create an HTTP tunnel. Keep the tunnel stopped until local verification and security checks are complete.
Get Started Free →
