conversun/fnos-apps: a third-party .fpk store for fnOS, built from a Shell sync pipeline

The gap fnOS leaves for a third-party .fpk store

fnOS is a NAS operating system, and its own application catalogue is the sanctioned way to install software on it. The projects that homelab users actually want, Plex, Emby, Jellyfin, Immich, Sonarr, Radarr, qBittorrent, Vaultwarden, arrive upstream as Docker images, tarballs or Debian packages, not as fnOS packages. The usual workaround is to run them under Docker and manage Compose files by hand, which means you own port mapping, volume paths, upgrade sequencing and rollback for every service.

conversun/fnos-apps exists to remove that step for fnOS specifically. It is a packaging repository, not an application. Each entry under apps/ corresponds to one upstream project, and the repository's job is to turn that upstream release into a .fpk file that fnOS can install through its normal package mechanism. The README also points at a companion app centre, fnOS Apps on port 8011, described as the way to install and update the rest in one place. The audience is narrow and clearly defined: fnOS owners who want native packages and are willing to take them from a third party rather than from the OS vendor.

What the repository actually contains: one directory per app, one release per version

The layout is flat and predictable. Every application lives in its own directory, apps/<name>/fnos/, and the README's tables reference an ICON.PNG inside that path. The fnos subdirectory name signals that the packaging metadata is platform-specific: whatever manifest, install script and icon fnOS expects sit together, separate from any shared build logic at the repository root.

The README's tables are the real inventory. They are grouped by function (AI, media services, and further categories that the supplied excerpt truncates) and each row carries an app name, a default port, a one-line description, an upstream source link and a release link. That port column is more useful than it looks: it is the repository's own statement of what each package will bind to, so Jellyfin on 8097, Immich on 2283, qBittorrent's neighbours, Frigate on 8971, Vaultwarden's peers, are all declared rather than discovered. Two entries collide on 8088 (CoPaw and QwenPaw) and two on 5055 (Jellyseerr and Seerr) and two on 5800 (tinyMediaManager and HandBrake), which is a packaging reality rather than a bug: they are alternatives, not co-installable defaults.

The count is inconsistent in the material. The repository description says 115 applications, the README badge says 157. Treat the number as a moving target that the daily sync keeps changing.

The daily sync: releases are versioned snapshots, not source builds

The release naming tells you how the pipeline thinks. Tags look like vibenvr/v1.35.3, transmission/vlatest-2026.09.10 and sub-store/v2.39.0, and the release titles read "Transmission latest-2026.09.10 for fnOS". The pattern is <app>/<upstream-version-or-latest>-<date>. A date-stamped "latest" tag means the repository re-checks upstream on a schedule and publishes a new package when the upstream artefact changes, even if the upstream version string does not. The three sample releases all carry timestamps within seconds of each other on 2026-09-10, which is consistent with a single batch job walking the app list and publishing per-app releases as it goes.

That design has a consequence worth stating plainly. Because the repository repackages upstream artefacts rather than compiling them, the trust boundary is the upstream release, not this repository. The Shell code decides which upstream version to fetch, how to lay it out inside the fnOS package format, and what the install scripts do. When an upstream project publishes a broken build, the next daily run will package it. There is no staging window described in the material, and no signature or checksum verification step is mentioned.

Getting it running: install the app centre, then install from it

The documented path is short. The README recommends installing the fnOS Apps application centre first, described as the way to "一键管理以下所有应用的安装与更新" (manage installation and updates for all the listed apps in one action). That package is itself listed in the tables as fnOS Apps, on port 8011, with its own source repository at github.com/conversun/fnos-store.

If you skip the app centre, the alternative is per-app: follow the release link in the table row, download the .fpk asset, and install it through fnOS's package installer. The README does not spell out the fnOS-side command for that in the supplied material, so the exact CLI invocation is not something I can give you.

What the material does give you is a set of default credentials and ports you will meet immediately after install. Koel ships with admin@koel.dev / KoelIsCool. Nanobot's web panel defaults to admin/nanobot. PicoClaw exposes a WebUI on 18800 and a gateway on 18790. LocalAI listens on 8185 with an OpenAI-compatible API, which means anything you point at it needs that base URL rather than the default OpenAI endpoint. These are first-login facts, and they are the kind of thing a packaging repository can only document, not enforce.

Where this is the wrong tool

The most obvious limit is platform lock-in. Every artefact here is a .fpk for fnOS. If you run TrueNAS, Unraid, plain Debian or a Kubernetes cluster, none of it applies, and the app centre on port 8011 is useless to you. The repository's entire value is the last mile into one operating system.

The second limit is the update model. A daily sync that follows upstream means your NAS can change underneath you without your involvement. For a media server that is usually tolerable. For Vaultwarden, which the repository description lists, or for Frigate with its camera streams, an unattended version bump is a different risk class. The material does not describe pinning, hold-back, or per-app update policy, so if you need to freeze a version you are doing it outside the tool.

The third limit is that packaging is not maintenance. The repository does not patch upstream bugs, does not backport security fixes, and does not audit what it ships. When the README lists an app with a default password, the repository has told you the default; it has not made the app safe. And because the README badge claims MIT while the repository metadata says GPL-3.0, you should not assume the licence question is settled by reading the top of the README.

Compared with running the upstream Docker images yourself

The realistic alternative is not another fnOS store, because the material does not name one. It is Docker. Almost every application in the tables publishes an official container image, and the README's source column points back to those upstream projects. Running Immich or Jellyfin as a container on fnOS means you choose the tag, you control the volume mounts, and you decide when to pull.

The difference in approach is who owns the last mile. With conversun/fnos-apps, a Shell pipeline owns it: it decides the upstream version, produces the .fpk, and publishes a release you install. With Docker, you own it: you write the Compose file, and the upgrade is a tag change you make deliberately. The first is less work and less control. The second is more work and gives you a rollback story you wrote yourself. There is a middle option too, which is to use this repository to discover what exists and which port each app expects, then run the upstream image directly. The port tables make that easy, and nothing in the material prevents it.

Maintenance cost and the licence question

Your maintenance burden here is not the build, it is the review. Because releases are cut daily and tagged with dates, the update stream is continuous. Someone has to decide, per app, whether to take the new .fpk now or wait. The repository gives you the version string in the tag and the app name in the tag prefix, which is enough to script a filter, but nothing in the material suggests the repository provides that filter for you.

On licensing: the repository metadata states GPL-3.0, and the README carries an MIT badge. Those are different licences with different obligations, and the discrepancy is visible in the material rather than something I am inferring. GPL-3.0 on the packaging code would not automatically relicense the upstream applications, which keep their own licences (Plex and Emby are commercial, Jellyfin is GPL, and so on). The practical point is that you should read the LICENSE file at the repository root and the licence of each upstream app you install, rather than trusting a badge. I am not giving legal advice; I am pointing at a contradiction you can resolve in one file.

Editorial conclusion

Adopt conversun/fnos-apps if you run fnOS and want Jellyfin, Immich, qBittorrent or Vaultwarden installed as native .fpk packages instead of hand-managed Docker Compose files, and if you accept that a Shell repository is now part of your update path. Do not adopt it if you need an audited supply chain, if you are not on fnOS, or if the applications you care about are not in the apps/ tree. Before installing anything, verify three things yourself: that the .fpk release assets are actually attached to the tagged releases, that the default credentials listed in the README (for example admin/nanobot, admin@koel.dev/KoelIsCool) are changed at first login, and that the GPL-3.0 LICENSE file at the repository root is the licence you are relying on, since the README badge says MIT.

Official sources

1. conversun/fnos-apps on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases