FrozenGEE compose templates target the NAS systems people actually own

The repository is organised by NAS brand, and the numbers are the index

FrozenGEE compose is a collection of Docker Compose templates, and its organisation is the first thing to understand because it is unusual. The top level of the repository is a set of numbered directories in square brackets, each one a NAS platform or a network strategy.

The list is [00] 通用模板 for general templates, [01] MACVLAN网络-独立IP for macvlan networking with independent IP addresses, [02] unRAID, [03] 群晖 for Synology, [04] 威联通 for QNAP, [05] 飞牛OS for fnOS, [06] 特殊版本 for special versions, [07] 铁威马 for TerraMaster, [08] 万由, [09] 单独合集 for a separate collection, [10] Rockchip and [11] 绿联 for UGREEN.

The numbering means the folders sort in a deliberate order, with the generic templates first and the platform-specific ones after. Someone arriving from a search engine lands on the README and picks their platform by number.

The whole set is a single repository, so getting the templates means taking the repository and picking the folder for your platform:

git clone https://github.com/FrozenGEE/compose

[09] 单独合集 is the one that changes meaning. The update log dated 2026-08-19 says that some projects that update frequently, and AI related projects, were moved into it. The author also notes, with some humour, that they personally do not often tinker with AI. So [09] is a fast-moving corner of the collection, separated out because it changes more often than the rest.

[01] is the other one with a distinct purpose. Macvlan with an independent IP puts a container on its own address on the local network, which is what you want for a service that needs to be reachable at a stable address without port mapping. That is a networking decision rather than a platform decision, which is why it sits apart from the per-brand folders.

The author recommends DPanel or Portainer, and explains the SSH catch

The README states a preference clearly: the templates are strongly recommended to be used with DPanel or Portainer, while other tools are your own choice, and the difference is small enough not to worry about.

That is worth understanding because it is not a template format but a tooling recommendation. DPanel and Portainer are graphical managers for Docker, and both can edit a compose file in place, which is what makes the heavily commented templates practical to use. The project also keeps separate deployment guides, portainer.md and dpanel.md, for each.

There is a catch the README explains, and it is a real one. Some NAS devices need SSH in order to deploy Portainer, because Portainer requires permission to access the Docker core. On those devices the web interface cannot select a path, so the deployment has to be done over SSH, and the README points to the command in the documentation further down.

That is a genuine constraint of running Docker on consumer NAS hardware rather than a flaw in the templates. The underlying reason is that the NAS web interface is a limited user interface over the same Docker API, and a container that needs to bind a host path or create privileged resources needs a path the web interface does not expose.

The portainer.md guide is struck through in the documentation list at the bottom of the README, which suggests it has been retired in favour of the DPanel guide, while the other reference documents remain current.

The templates use host networking, and the ports block is commented on purpose

The network mode is a deliberate choice, and the README explains it in two paragraphs that are the most practically useful text in the file.

The templates are mostly host network mode, on the grounds that the author prefers to customise the container's internal port where possible and then use host mode. In host mode a container shares the host's network namespace, so it binds directly on the host's addresses and there is no port mapping at all.

The second half is the trick, and it is the kind of detail that saves an afternoon. UGREEN and fnOS Docker both support quickly opening a WebUI based on the container's port mapping, but only for containers that have a port mapping, and they do not support it for host mode because that mode needs no port mapping. The recommendation is therefore to use host network mode and also uncomment the ports block and the port mapping underneath it, so that even though that part does not take effect, you still get the quick WebUI shortcut.

The README also notes that UGREEN and fnOS have desktop clients for creating shortcuts to a container's WebUI, though fnOS does not have a desktop client yet, and that the mobile side has no such facility, which is why it recommends this trick.

A third point covers the same families: some NAS devices have the characteristic described above and others may differ, so the two examples given should be treated as examples rather than as a rule. The author is explicit about that limit rather than claiming a general behaviour.

The other operational detail is that the templates have many variables that are not simplified, described as accidentally intentional, along with a large amount of comment text explaining the purpose of the parameters and some useful information, with the admission that there is a lot of filler.

Docker updates replace the container, which is why path mapping is the thing to get right

The README has a section on a small piece of Docker knowledge that determines whether a NAS setup is portable, and it is the part that most affects how you should read the templates.

A Docker update, the README explains, is really uninstalling the currently deployed container and then deploying a new one with the same configuration. If you look closely you can see that the container ID changes with every update.

That property is useful once you understand it. As long as you map the paths properly and put the necessary things on the NAS's real paths, then when the NAS changes you can package up everything that was mapped and move it to the new NAS, adjust the configuration to match the new reality, and recover the deployment. The README says Portainer can show which volumes are not mapped, in the volume section on the left, and those residual volumes can be deleted.

The author then draws the conclusion about tooling: this is the reason they prefer Docker over packages on a Synology, and they recommend the same approach to others.

This is the single most important thing to internalise before deploying any of these templates, and it is why the reference documents matter. volumes.md explains the NAS path conventions, ports.md the default ports, and uid_gid.md the permissions of the first user. Those three files are the difference between a template that works on your NAS and one that silently writes to the wrong place or runs as the wrong user.

The documentation set is the actual product

The reference documents listed at the bottom of the README are the parts of this repository that carry information rather than configuration.

There are seven entries. volumes.md covers NAS path conventions, ports.md covers default ports, uid_gid.md covers the permissions of the first user on the NAS, logo.md explains how to use the logo icons, compose.md covers other configuration parameters for the compose templates, and dpanel.md and portainer.md are the deployment guides for each of the two recommended tools.

What is missing from that list is as informative as what is in it. There is no guide to a specific service, no per-template README, and no automated test of any template. The knowledge is organised around the platform and the tool, not around the application, which means that if you are looking for how to run one particular piece of software, you are reading a template and inferring the configuration from the comments.

The WHAT'S_OLD.md file is the changelog archive. The README's update log section is dated 2026-08-19 and says the author cleaned up some content, moved frequently refreshed and AI related projects into [09], and that the fnOS unless-stopped problem is solved, with image export and import now supported, and that the only remaining gap is one-click compose update without stopping the container, while the compose text editor fullscreen problem is solved. The dpanel compose text editor can also be maximised now.

The project also points at a separate project it recommends, 骏耀K歌 · junyao-ktv, and the reasoning given is that in the AI era it is good to live long enough to see things, since previously a NAS could only run a karaoke system by buying a specific QNAP model.

AGPL-3.0, an unusual release tag, and a repository that reads as a personal notebook

The licence is AGPL-3.0, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. For a collection of configuration files the AGPL is unusual, since it is the licence of the copyleft family designed for software, and it is worth knowing if you plan to redistribute a modified set of templates.

The release record is thinner than the commit record. The only tagged release is a logo asset, named logo with a version of logo-2024-10-27, dated 2024-10-27, while the last push to the repository was on 2026-08-19, which matches the date of the update log at the top of the README. The repository is not archived.

The primary language is listed as unknown, which is consistent with the content: YAML compose files, Markdown documents and a few images, with no program to speak of.

The README itself states the intent in a tone that is unusual for a technical repository. The description says it shares compose templates so that newcomers and experienced users can deploy Docker containers quickly, that the comments are plentiful, that the amount of text is huge with a warning that it may put you off, and that the author was too lazy to build a site or a blog and uses GitHub as the blog instead. There is a Star History chart at the bottom and a link to the historical changelog.

That self-description is the honest framing of the project. It is a personal collection maintained by one person, where the value is the accumulated per-NAS knowledge in the comments and the reference documents, and where the templates are the author's own working configurations rather than configurations anyone else has validated.

Editorial conclusion

Adopt FrozenGEE compose if you run containers on a NAS and want a starting configuration for a service rather than writing the compose file and the path mapping yourself, and if you are willing to read the comments, which the project says are extensive and deliberately so. Do not adopt it if you need maintained upstream configurations, because these are community templates that will drift as the images they reference change, and the only tagged release in the repository is a logo asset from 2024. Before you deploy anything, read volumes.md, ports.md and uid_gid.md for your specific NAS, because the same template behaves differently on a Synology and a UGREEN box, and check the path mapping so a migration does not lose your data.

Frequently asked questions

Official sources

1. FrozenGEE/compose on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases