# mos-releases is where the MOS home server images are assembled

> MOS is a modular operating system for home servers built on Devuan, with Docker, LXC and QEMU included and storage handled by mergerfs and SnapRAID rather than RAID. This repository does not hold the operating system itself, it builds the bootable images and archives from the kernel, root filesystem and driver components.

**mos-nas/mos-releases** — A Modular Operating System for Servers and Homelabs

- Repository: https://github.com/mos-nas/mos-releases
- Website: https://mos-official.net
- Stars: 653 · Forks: 20
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mos-nas-mos-releases

## A build repository, not the system itself

The scope of this repository is stated plainly near the end of the README: it is responsible for assembling and building MOS release artifacts, combining the MOS kernel, root filesystem and drivers into bootable images and ZIP archives. That is a useful clarification for anyone arriving at the mos-nas organisation expecting to find the source of an operating system here. The tree is small and says the same thing: a .github directory, a LICENSE, the README, a SECURITY file, a THIRD_PARTY file, an images directory, a runner setup script and a runner file for the MOS releases workflow. The system itself lives in sibling repositories, and the README lists them in a way that maps the architecture. The kernel and the root filesystem are the base, the Docker, LXC and QEMU packages are the container and virtualisation layer, the Notify, image-sha, mergerfs, SnapRAID and docker-watchdog packages are MOS specific, and the boot files and GRUB repositories are the custom repositories. The frontend and the API are separate projects too, so the web interface you see is not part of the image build.

## Devuan underneath, with the heavy lifting included by default

MOS is described as a lightweight operating system based on Devuan, designed specifically for small, energy efficient home servers, with a primary goal of a simple, reliable and low overhead platform for self hosting, virtualization and homelab environments. The design decision that follows from that is that the expensive-to-configure parts ship in the box. Docker, LXC and QEMU are supported by default, alongside a set of essential system tools, which means an image can be booted and immediately run containers or virtual machines without a package installation marathon. Devuan as the base is a notable choice, since it is a Debian derivative without the systemd init, which aligns with a project that lists no hidden services as part of its design philosophy. The stated audience is homelab users, self hosters, developers and anyone looking for a minimal, efficient server operating system with modern tooling, and the design principles are simplicity, transparency and modularity, with no hidden services, no telemetry and no forced cloud dependencies.

## Storage is mergerfs and SnapRAID, not RAID

The storage approach is the most opinionated part of the system and the part with the most operational consequences. Two tools are included by default. mergerfs allows combining multiple disks into a single unified filesystem, which the README frames as ideal for expandable storage setups, so you can add a disk later without restructuring an array. SnapRAID provides snapshot based parity protection for data disks, optimised for media and home server use cases. The stated benefit of the combination is a flexible and easy to manage storage solution without the complexity of traditional RAID, and the wording is telling, because parity protection with scheduled snapshots behaves quite differently from a RAID array in terms of rebuild times and failure semantics. A reviewer should treat that as a design decision to be comfortable with rather than a simplification. Additional storage technologies are offered through MOS Hub as optional driver plugins, with nonraid named as the example. The project also keeps backups firmly in view, stating that while filesystem issues are not expected you should always keep backups of important data.

## Hardware support arrives as optional plugins

MOS supports hardware drivers distributed as optional plugins, and the list is where you should look before committing to the platform. It includes NVIDIA drivers, DVB drivers, a backup plugin, Nonraid drivers with user interface support, ZFS drivers without user interface support, an SR-IOV i915 driver, and a Google Coral driver for edge inference accelerators, with the list continuing beyond what the README enumerates. The asymmetry in that list is worth noting, since the Nonraid driver has interface support and the ZFS driver does not, so a plugin is not automatically a first class feature with a full management surface. The architecture is consistent with the modularity claim, and it also means the base image stays small, but it introduces a dependency on MOS Hub, a separate distribution channel for plugins, and a coupling to the driver packages that a conventional distribution would handle in the kernel tree. The README notes that adding and removing features via plugins is still work in progress, which places that mechanism squarely in the category of settling.

## From a command line system to a Swagger interface

The history of the project explains the shape of what you install. MOS started as a personal project built out of necessity, and initially it was nothing more than a command line only system. A friend asked whether they could use it as well, and that request led to the development of a REST API, after which a frontend was added step by step. That API is documented through Swagger, reachable at the api-docs path on the host address of the machine. The consequence for a user is that the graphical interface is a layer on top of an API, not a separate product, and the API is the part that is useful for scripting. The project is also described as including almost full automation on GitHub, with a workflow badge for creating releases and a runner script in the tree, so the image build is reproducible from the repository rather than assembled by hand.

## Eight gigabytes of memory and an x86_64 processor

The minimum hardware requirements are given as recommendations, and they are modest for something that runs virtual machines. The processor needs to be x86_64 compatible, the memory requirement is 8GB of RAM, and storage needs a USB flash device or an HDD, SSD or NVMe to install the operating system, with the note that additional disks are recommended for mergerfs and SnapRAID setups. Networking needs Ethernet or a compatible network interface. The README connects those requirements to stable operation of containerized workloads, virtualization features and storage services, which is the honest way to read them: the floor is set by the workloads you want to run rather than by the system itself. The USB flash option is worth pausing on, since it makes the system disposable and easy to reimage, and a homelab operator with a spare stick can treat installation as a repeatable operation rather than a one off.

## Licensing differs per component, and third party code keeps its own terms

The licensing section is careful in a way that many distribution projects are not. The contents of this repository, described as build scripts, configuration files and automation, are licensed under the licence in the LICENSE file, and the repository listing identifies that as GPL-3.0. Different MOS components and repositories may use different licences, and the README says this does not affect the licensing of third party software included or packaged by MOS, which always remains under its original upstream licences. For anyone shipping a MOS based product, that is a two part question: what the MOS build scripts require of you, and what each packaged component requires. The THIRD_PARTY file in the tree is where the second half is recorded, and the README points to the individual repositories for the detail. The project status section is equally direct, providing the operating system as is, noting that bugs can occur at this stage, and asking that any problems be filed as issues in the appropriate repository rather than worked around locally.

## Conclusion

MOS suits a homelab operator who wants a small, self assembled server operating system with a web interface for the parts that matter, and who accepts that the platform is young and that the driver set is plugin based. It is the wrong choice if you need a distribution with long term support commitments, formal hardware certification or a community that will still be there in five years, since the project describes itself as started as a personal solution and still evolving. Verify three things before you install it: that your hardware is covered by one of the optional driver plugins, especially for GPU and network devices, that you understand the mergerfs and SnapRAID layout you are creating, because the project recommends keeping backups even though filesystem issues are not expected, and which licence applies to the components you are redistributing, since this repository is GPL-3.0 while other MOS repositories may differ. The latest release is 0.6.0-stable from 2026-10-04.

## FAQ

### What is the MOS operating system built on?

It is based on Devuan and is described as a lightweight operating system designed for small, energy efficient home servers, with Docker, LXC and QEMU support included by default alongside essential system tools.

### What does the mos-releases repository contain?

It is responsible for assembling and building MOS release artifacts, combining the MOS kernel, root filesystem and drivers into bootable images and ZIP archives. The tree holds the build and automation scripts, an images directory and a third party file.

### How does MOS handle storage and RAID?

mergerfs is included to combine multiple disks into a single unified filesystem, and SnapRAID provides snapshot based parity protection for data disks. The README describes this as a flexible storage solution without the complexity of traditional RAID, and it recommends keeping backups of important data anyway.

### What hardware does MOS need, and how are extra drivers added?

The recommended minimum is an x86_64 processor, 8GB of RAM, Ethernet networking and a USB flash device or disk to install the system, with additional disks recommended for mergerfs and SnapRAID. Hardware drivers such as NVIDIA, DVB, ZFS, SR-IOV i915 and Google Coral come as optional plugins.

## Sources

- [License: GPL-3.0](https://github.com/mos-nas/mos-releases/blob/master/LICENSE)
- [mos-nas/mos-releases on GitHub](https://github.com/mos-nas/mos-releases)
- [Project website](https://mos-official.net)
- [README](https://github.com/mos-nas/mos-releases/blob/master/README.md)
- [Releases](https://github.com/mos-nas/mos-releases/releases)

---

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