# conversun/fnos-apps: a third-party .fpk app store for fnOS NAS

> A packaging repository that builds installable .fpk bundles for 115+ self-hosted apps on 飞牛 fnOS, with an optional app center on port 8011. Here is how the sync works, how to install a package, and where it stops being the right tool.

**conversun/fnos-apps** — 飞牛 fnOS NAS 第三方应用商店 — 115 款自托管应用的 .fpk 安装包 | Plex, Emby, Jellyfin, qBittorrent, Immich, Sonarr, Radarr, Vaultwarden, ZeroClaw AI, OpenClaw 等 | 每日自动同步上游版本

- Repository: https://github.com/conversun/fnos-apps
- Stars: 757 · Forks: 71
- Language: Shell
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/conversun-fnos-apps

## What conversun/fnos-apps actually packages, and for whom

飞牛 fnOS is a NAS operating system, and like most NAS systems it expects applications to arrive as signed package files rather than as a shell script you paste into a terminal. The .fpk format is that package format. conversun/fnos-apps is a build repository that takes upstream self-hosted applications and produces .fpk files that fnOS will accept.

The audience is narrow and specific: someone who already runs fnOS on their own hardware and wants Plex, Emby, Jellyfin, Immich, qBittorrent, Sonarr, Radarr or Vaultwarden available from the system's own app management rather than from a Compose file. The repository description puts the count at 115 applications, while the README badge reads 157, so treat any single number as approximate and check apps.json for the current list.

What it is not: it is not a fork of those applications, and it is not a container runtime. The packaging repository is written in Shell and licensed GPL-3.0, and each entry points at an upstream project hosted elsewhere. If an upstream project breaks, this repository can only ship the newer or older upstream build.

## How the daily upstream sync and .fpk build pipeline work

The repository layout tells most of the story. There is an apps/ directory holding one folder per application, a scripts/ directory, a shared/ directory, plus apps.json and recommended.json at the top level. The README states that upstream versions are tracked automatically and that builds produce directly installable .fpk packages.

The release tags confirm the pattern. A release is named after the upstream project and its upstream version, with a date suffix for rolling upstreams: vibenvr/v1.35.3, sub-store/v2.39.0, and transmission/vlatest-2026.09.10. That last one is the interesting case. Transmission publishes no stable version number here, so the packaging repository encodes the sync date into the tag instead. It means an update exists when the date changes, not when a semantic version changes.

The practical consequence is that the version you install is the upstream version, and the packaging layer is the part maintained here. Fixes to how an app is wired into fnOS (ports, data directories, service user) arrive through this repository; fixes to the application itself arrive from upstream and are only as fast as the sync. The last push to the repository was on 2026-09-10, the same day as the three releases listed, which is consistent with a scheduled job that commits and releases together.

## Installing a first app: the app center and a manual .fpk

There are two routes. The README recommends installing the fnOS Apps app center first, because it manages installation and updates for everything else. It listens on port 8011 and is distributed from a separate repository, conversun/fnos-store.

If you prefer to install a single package by hand, the flow is the standard fnOS one: download the .fpk from the release page for that app, then install it through the system's package interface. The repository does not document a CLI installer, so the exact upload command depends on fnOS itself, not on this project.

The one piece of configuration worth reading before you install anything is the port table, because several apps in the list collide. CoPaw and QwenPaw both list port 8088. tinyMediaManager and HandBrake both list port 5800. Jellyseerr and Seerr both list port 5055. LyraNest and Open WebUI both list port 8080. If you install both members of a pair, one of them will not bind.

A few apps also ship default credentials that you should change immediately after first login. The README gives these directly:

```text
Nanobot   : admin / nanobot
Koel      : admin@koel.dev / KoelIsCool
```

After install, the app should appear in the fnOS application list and answer on its documented port, for example 2283 for Immich, 32400 for Plex, 8097 for Jellyfin and 4533 for Navidrome. If it does not, the first thing to check is whether another installed app already owns that port.

## Where the packaging model breaks down

The most obvious limitation is platform lock-in. Every artifact here is a .fpk built for fnOS. None of it is useful on TrueNAS, Unraid, Synology or a plain Debian server. If you are still choosing a NAS platform, this repository should not influence that decision, because it only exists downstream of one.

Second, the sync is only as good as its upstream. The README says versions are tracked automatically, but an upstream project that changes its data layout, its configuration format or its default port between releases will break a package until the packaging is adjusted. There is no documented rollback procedure in the README, so pinning to an older release tag and reinstalling is the practical fallback.

Third, the port collisions listed above are a real operational hazard on a single NAS, and the README presents the table without warning about them. Anyone installing several media apps from this list will hit one.

Fourth, and most important for a production home server, this is a community packaging effort with no stated support commitment. The README does not describe a testing policy, a compatibility matrix per fnOS version, or a security review process for upstream updates. For Vaultwarden or Immich, which hold credentials and personal photos respectively, that gap matters more than it does for a music server.

## conversun/fnos-apps versus running your own Docker Compose stack

The honest alternative is not another app store. It is Docker Compose, which most of these upstream projects publish themselves. Immich, Vaultwarden, Frigate and the *arr applications all ship official container images and compose files, and fnOS can run containers.

The difference in approach is who owns the upgrade path. With Compose, you edit a YAML file, pin an image tag, and run docker compose pull && docker compose up -d when you decide to move. You control the version, the volumes and the network. With conversun/fnos-apps, you get a click-to-install package whose data directories and service wiring were chosen by the packager, and whose version moves when the daily sync moves.

Compose costs you more setup per app and gives you a portable configuration you can move to another machine. The .fpk route costs you almost nothing per app and gives you a configuration that only exists on fnOS. Neither is wrong. The deciding question is whether you want to manage ten YAML files or trust ten packagers.

## Maintenance cost, licence and what to verify before adopting

The repository itself carries GPL-3.0. The README's own badge claims MIT, which contradicts the licence identifier given for the project; treat that as a documentation inconsistency and read the LICENSE file before you rely on either. Note also that GPL-3.0 covers the packaging repository, not the applications inside it. Plex, Emby and several others are proprietary or under their own terms, and the README links to their official sites rather than restating their licences. This is not legal advice; if you redistribute .fpk files, check each upstream licence separately.

Maintenance cost has two layers. The packaging layer updates itself: the last push was on 2026-09-10 and the release tags show same-day builds, so the sync job appears to run on schedule. The application layer is yours: you still have to watch upstream release notes for breaking changes, back up data directories before major upgrades, and resolve port conflicts by hand. The app center on port 8011 reduces the clicking, not the risk.

Before committing, open apps.json and confirm the apps you need are present with the ports you expect. Check the release tag for the version you want, remembering that rolling upstreams are tagged by date. And confirm your fnOS version is one the packages were built against, since the README does not publish a compatibility table.

## Conclusion

Adopt conversun/fnos-apps if you run 飞牛 fnOS and want Plex, Immich, qBittorrent or Vaultwarden installed as native .fpk packages rather than hand-managed Docker containers, and if you accept that each package is a build of someone else's upstream project. Do not adopt it if you run TrueNAS, Unraid or plain Linux, since the output is fnOS-specific, or if you need a support contract behind every app. Before installing anything, verify three things yourself: that the app appears in apps.json with a port that does not collide with an existing service, that the release tag matches the upstream version you actually want, and that the GPL-3.0 licence of this packaging repository is compatible with how you plan to redistribute the resulting .fpk files.

## FAQ

### What does fnOS stand for in conversun/fnos-apps?

The repository describes itself as a third-party application packaging repository for 飞牛 fnOS, a NAS operating system. The README does not expand the abbreviation, so the name is best read as the product name of the NAS platform rather than an acronym with a documented meaning.

### What is the purpose of conversun/fnos-apps?

It automatically tracks upstream versions of self-hosted applications and builds .fpk packages that install directly on 飞牛 fnOS. The README recommends installing the fnOS Apps app center on port 8011 first, which then manages installation and updates for the rest of the catalogue.

### How do I install an app from conversun/fnos-apps?

Download the .fpk from the release page for that application and install it through fnOS, or install the fnOS Apps app center on port 8011 and use it to install and update everything. The README does not document a command-line installer.

### Which ports do the apps in conversun/fnos-apps use?

The README lists a port per app, for example 2283 for Immich, 32400 for Plex and 8097 for Jellyfin. Several entries collide: CoPaw and QwenPaw both use 8088, tinyMediaManager and HandBrake both use 5800, and Jellyseerr and Seerr both use 5055.

### Is conversun/fnos-apps the same as fnOS itself?

No. It is a third-party packaging repository that produces .fpk packages for fnOS, and the README labels it as third-party. The applications it packages come from independent upstream projects, each linked from the README.

## Sources

- [conversun/fnos-apps on GitHub](https://github.com/conversun/fnos-apps)
- [Issues](https://github.com/conversun/fnos-apps/issues)
- [License: GPL-3.0](https://github.com/conversun/fnos-apps/blob/main/LICENSE)
- [README](https://github.com/conversun/fnos-apps/blob/main/README.md)
- [Releases](https://github.com/conversun/fnos-apps/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/conversun-fnos-apps