Install fnOS Apps and Add Remote Access with Localtonet

What fnOS Apps is and what this guide installs

The names around this project can be confusing at first. The fnos-apps repository is a packaging repository for third-party applications that can run on fnOS NAS systems. It tracks upstream software and produces directly installable .fpk packages. Its catalog includes media servers, download tools, content-management systems, monitoring applications, development tools, automation platforms, file services, and networking utilities.

The component installed in this guide is the fnOS Apps Store, also described as the fnOS Apps application center. It is a separate web interface designed to browse, install, and manage packages from that catalog. Installing the application center does not automatically install every application in the repository. Instead, it gives you a central interface from which you can select the individual applications you want.

This distinction matters when planning remote access. Port 8011 belongs to the fnOS Apps Store interface. An application installed from the store normally has its own service port. For example, a monitoring dashboard, media server, or file manager will not automatically become available through a tunnel pointed at port 8011. If you later need remote access to an installed application, verify that application's documented local endpoint and create a separate, appropriately secured tunnel.

Prerequisites and decisions to make before installation

The project publishes installable packages, but its current project documentation does not provide a complete model-by-model fnOS compatibility matrix or a fully illustrated fnOS installation procedure. The safest approach is to confirm the following items on your own NAS before downloading a package.

A working fnOS NAS

You need administrative access to a running fnOS system and permission to install a local or manually supplied application package. The exact wording and placement of the local-install control may differ between fnOS releases. It may appear as Local install or Manual install in the App Center. If neither option is present, check the documentation for your installed fnOS release rather than enabling undocumented settings.

The NAS CPU architecture

fnOS Apps Store releases provide separate .fpk assets for x86 and ARM systems. Choose the package corresponding to the processor architecture of the NAS. Do not infer architecture from the appearance of the fnOS interface or from the applications already installed. Confirm it through the NAS system-information view or the hardware manufacturer's documentation.

A trusted package downloaded from the project release

Obtain the application-center package from the project's release assets. Release filenames include the store version and architecture. Exact filenames change as versions are published, so this guide does not hardcode a version-specific download URL or tell you that a particular release will remain the latest.

Before uploading the file, verify that its extension is .fpk and that you selected an asset for the application center rather than an unrelated application from the larger package repository. A release for Grafana, Jellyfin, or another catalog application is not the fnOS Apps Store installer.

Local network access for initial verification

Complete installation and testing from the local network first. You should know the LAN address or resolvable local hostname of the NAS and be able to reach it from a browser on the same network. You will use that address with port 8011 after installation.

A device capable of running the Localtonet client

For remote access, the Localtonet client must run on a device that can reach the fnOS Apps service. It may run on the NAS if a compatible client installation is currently available for that environment, or on another always-on device on the same LAN. Because verified client installation commands and current platform-specific package details were not supplied for this article, use the current Localtonet installation flow for the selected operating system rather than copying an unverified command.

Install the fnOS Apps Store package

The project confirms that the application center is distributed as an installable fnOS package and recommends installing it from a release. The exact prompts displayed by fnOS are version-dependent and are not fully documented by the project. The sequence below therefore stays within the established fnOS local-package workflow and deliberately avoids inventing package-specific wizard fields.

No shell command is required for this documented package-install path. The store repository includes commands for running its source code in a development environment, but those commands are for developers and are not a substitute for installing the packaged fnOS application. In particular, a development setup involves a Go backend and a separate frontend development server. That is a different workflow from uploading the release .fpk.

Start and verify the fnOS Apps Store locally

Do not create a public tunnel immediately after the package installer finishes. First confirm that fnOS considers the application installed, that the service is running, and that its web interface responds from the LAN.

Open the installed application from fnOS

Locate the fnOS Apps Store in the installed-applications area or on the fnOS desktop. If fnOS provides a start control and the application is stopped, start it there. The exact label and icon placement can vary by fnOS release, so use the application state shown by your NAS rather than assuming that successful installation automatically means the process is running.

Test the documented default endpoint

The application-center backend documents port 8011 as its default listener and identifies its server as HTTP-based. From a browser on the same LAN, open:

http://NAS-LAN-ADDRESS:8011/

Replace NAS-LAN-ADDRESS with the actual private address or local hostname of the fnOS system. For example, use the same LAN identity that other devices use to reach the NAS. The placeholder above is intentionally not a real address.

A successful result is the fnOS Apps Store web interface loading in the browser. Confirm that page assets render correctly and that you can browse the application catalog. If the interface offers status or update information, give it enough time to retrieve its catalog before treating a temporarily empty page as a permanent failure.

Distinguish browser errors from application errors

A timeout usually means the browser cannot establish a connection to the NAS and port. A connection-refused message commonly means the address is reachable but no process is accepting connections on that port. An HTTP error page means the web server responded, which narrows the problem to the application or its configuration. A partially rendered page may indicate that the backend is available while frontend resources or upstream catalog data are unavailable.

Use the store for installation and update operations

Once local verification succeeds, the fnOS Apps Store can act as the management interface for the broader third-party package catalog. The documented interface supports browsing and installing applications, detecting available updates, displaying live installation progress with server-sent events, and batch updating.

Treat every catalog entry as an independent self-hosted system. The store can simplify package delivery, but it cannot make the operational requirements of unrelated applications identical. Before installing an application, review its architecture support, default port, persistent-storage needs, upstream image requirements, first-run credentials, and any hardware dependencies documented in its release.

Installing an application from the catalog

Select the desired application in the store and review the information presented before starting installation. Newer store releases can retrieve and display an application's own installation form when its package declares one. Such a form may request values such as a path, password, token, or other package-specific setting. Complete required fields carefully and never reuse a sensitive administrative credential merely for convenience.

Wizard behavior is version-dependent. Project release information indicates that if a wizard lookup fails, the store can fall back to treating the package as having no wizard. That fallback does not prove that default settings are appropriate for every application. If an application is known to require a secret, path, or integration value and no prompt appears, stop and check its current package documentation before proceeding.

Interpreting installation progress

The interface can report progress in real time using server-sent events. Keep the browser page open while a package is being downloaded and installed, especially for applications backed by large container images. A long operation is not necessarily stalled. Network speed, registry responsiveness, storage performance, and image size can all influence completion time.

Avoid refreshing repeatedly or submitting the installation action more than once. If progress stops, check whether fnOS still reports an active operation before attempting recovery.

Updating installed applications

Store versions and fnOS versions influence the available update path. Recent project releases describe a data-preserving update channel through the fnOS application-center service. Earlier releases sometimes directed users to update manually through the native fnOS App Center when the safer update path was unavailable.

Consequently, an enabled update button, a disabled manual-update notice, and an update failure have different meanings. Follow the status shown by your installed store version. Do not work around a blocked update by forcing an undocumented installation command over an existing application.

Do not assume all listed ports are web interfaces

The catalog records ports for many applications, but a port may represent a web interface, API, peer protocol, DNS service, media protocol, or another transport. Some applications use more than one port, and some system packages have no service port at all. Verify the protocol in the individual package or upstream documentation before choosing a Localtonet tunnel type.

Add remote access with a Localtonet HTTP tunnel

After the store works on the LAN, you can make its HTTP interface reachable through Localtonet. Our client establishes an outbound connection to a Localtonet relay server. The resulting HTTP tunnel provides a public HTTPS address without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

The Localtonet client does not have to be on the same operating-system process as the web application, but it must run on a device that can reach the target. If the client runs directly on the fnOS NAS, the local target may be reachable through a loopback address. If it runs on another LAN device, use the NAS LAN address. Test that exact address from the client device before creating the tunnel.

Use the following documented Localtonet sequence. Dashboard availability, relay choices, and some options can vary, so select values shown in your current account rather than copying a region or server code from an article.

For current dashboard details, use our Localtonet HTTP tunnel documentation. If you choose a custom domain, check the current documentation for its DNS requirements instead of applying an unverified record copied from another provider or an older guide.

Security considerations for a remotely reachable app store

An application store is an administrative interface. It can initiate software installation and update operations, so exposing it carries more risk than publishing a read-only status page. A working HTTPS tunnel protects the public web connection at the tunnel edge, but it does not automatically establish that the fnOS Apps Store itself has suitable user authentication, authorization, session controls, or protection against every application-layer threat.

The supplied project documentation does not establish a default login requirement for the fnOS Apps Store. Do not assume that authentication exists merely because the interface performs privileged work. Test the public URL in a private browser session that has no fnOS cookies. If the store opens directly and permits management actions, treat the endpoint as unauthenticated and do not leave it publicly running.

Use temporary access when possible

A practical pattern is to start the tunnel only when you need to inspect or manage the store remotely, complete the task, sign out, and then stop the tunnel. With Localtonet, the tunnel is available only while the selected client is connected and the tunnel is running. Stopping it removes the public route without changing the local fnOS installation.

Protect the Localtonet device token

The authentication token identifies the client device. Never place it in this article's target URL, a browser bookmark, a public repository, an fnOS screenshot, or a support transcript. If you believe it has been exposed, use the account controls available in the current dashboard rather than continuing to rely on a compromised value.

Expose one service, not the whole NAS

Point the HTTP tunnel specifically at port 8011. Do not substitute the main fnOS management port, Docker socket, SSH port, or an unrestricted reverse proxy merely to make setup easier. Each additional administrative endpoint increases the effect of stolen credentials or a vulnerable application.

Review every installed application's own security

Installing an application from the store does not place it behind the port 8011 tunnel. If you later expose another application, review its first-run account, default password, API token, upload behavior, and authorization model. Change any documented default credentials before remote exposure. Use the tunnel protocol that matches the application's actual network protocol.

Maintain backups and an update plan

Security also depends on keeping the store, fnOS, and installed applications maintained. Apply updates deliberately, preserve application data, and verify the service again after each significant change. If an update changes the local port or listening behavior, update the tunnel only after confirming the new endpoint on the LAN.

Troubleshooting installation, local access, and the tunnel

The .fpk package is rejected

Recheck that the file is an fnOS Apps Store release asset, not source code, a checksum file, a standalone server binary, or an individual catalog package. Confirm the package architecture against the NAS. Download the asset again if the transfer may have been interrupted. If fnOS reports an explicit compatibility or package-signing error, preserve the exact message and consult the release information rather than repeatedly retrying.

The package installs but the interface does not open

Verify that the application is running in fnOS. Confirm that you are using port 8011 and the NAS's current LAN address. If the NAS receives its address dynamically, it may have changed since the last session. Test from another device on the same network and avoid diagnosing the Localtonet tunnel until direct LAN access works.

The store loads on the NAS but not from another LAN device

This can indicate that the service is bound only to a loopback interface, that the NAS and browser are on isolated network segments, or that a local security policy is restricting access. The store's documented default listener is :8011, but the packaged runtime configuration controls actual behavior. Review the fnOS application state and package documentation before changing system firewall or binding settings.

The interface loads but applications cannot be installed

Separate store availability from package installation. The web interface can be healthy while an application download, container-image pull, storage operation, or package-specific wizard fails. Record the application name, version, architecture, and exact progress message. Check available storage and the NAS network connection. Do not assume that a failure in one catalog application means port 8011 is broken.

An update button says manual update is required

Respect that state. Project history shows that update availability can depend on whether the installed store can access a suitable fnOS update path. Use the native fnOS App Center when directed. Do not overwrite an existing application with a local-install shortcut unless the current package instructions explicitly identify that as a safe upgrade method.

The Localtonet client is connected but the public URL fails

Confirm all three lifecycle conditions: the selected client is connected, the tunnel has been created, and the tunnel has been started. Then test the configured target from the same device that runs the Localtonet client. If that device cannot open http://NAS-LAN-ADDRESS:8011/, the relay cannot make the application reachable.

The tunnel works only when the client runs on the NAS

Check whether the target was configured as 127.0.0.1. That address always points back to the client device itself. When moving the client to a different computer, replace the loopback target with the NAS LAN address and verify routing between the two devices.

The public page opens, but actions or live progress fail

First verify that the same action works through the local URL. The store uses server-sent events for live progress, so a page can initially render even when a longer-lived progress connection is interrupted. Capture the browser-visible error and test again after confirming both the local application and tunnel are running. Avoid claiming a protocol incompatibility without reproducing the behavior locally and remotely.

The public URL unexpectedly reaches another service

Stop the tunnel immediately and inspect the configured local IP and port. Make sure the port is 8011 and the target address belongs to the intended NAS. On networks with multiple NAS devices or reused dynamic addresses, a stale LAN address can point to the wrong host.

Frequently asked questions