Meet NithronOS (nOS): the local-first infrastructure OS that just works

NithronOS: Local-first infrastructure that feels like a product

If you’ve ever tried to stand up a homelab, a personal cloud, or a small office stack, you know the drill: a dozen conflicting tutorials, five different dashboards, and a weekend lost to yak-shaving.

NithronOS (nOS) is our answer to that mess. It’s an open-source, Linux-based OS for NAS and homelabs that puts storage, snapshots, shares, backups, and day-to-day operations behind a modern web dashboard, with an optional app catalog when you want it. The goal is simple: make self-hosting feel like using a product, not babysitting a project.

Repo: https://github.com/Nithron/NithronOS

What it does today (and why it stays out of your way)

nOS is local-first and privacy-first by design. The admin UI is meant to live on your LAN by default, and remote access is something you opt into, not something that “accidentally happens.”

Under the hood, nOS is Btrfs-first for snapshot-friendly storage flows, with optional ZFS support depending on platform constraints. In the current pre-alpha (v0.9.5), the project focuses on the fundamentals that make systems feel dependable: a real-time dashboard, health monitoring (including disk and SMART status), live storage metrics, and a Debian installer for a proper install flow instead of a pile of manual steps.

The “OS part” is only half the story. nOS also leans into composability: if it runs in a container, it likely runs on nOS. The included app approach is built around Docker and Compose, so common self-hosted staples (media servers, cloud apps, photo stacks) can be deployed without turning your machine into a one-off snowflake.

How it’s built: one stack, one mental model

A lot of homelab pain comes from mismatched interfaces and mismatched workflows: the UI says one thing, your scripts say another, and the underlying system behaves differently again. nOS tries to flatten that into one consistent mental model.

Architecturally, there’s a Go service (nosd) exposing a REST API for disks, pools, snapshots, shares, sync, jobs, and real-time health metrics, plus a privileged helper (nos-agent) for allow-listed actions that require elevated access.

The web UI is React + TypeScript, generated from OpenAPI and designed for live updates. A Caddy reverse proxy ties the UI and API together and can also provide WebDAV endpoints for sync clients. Scheduled maintenance (like snapshot pruning) runs via systemd timers.

File sync is also treated as a first-class feature via NithronSync, positioned as a OneDrive-like experience across desktop and mobile platforms, with token-based device auth and delta sync.

Safety and security are not “later” features

nOS makes a strong point about predictable operations, especially around updates. Pre-update snapshots and rollback are built-in and enabled, with a retention policy that keeps the newest snapshots per target by default. The intent is that upgrades feel routine and reversible, not heroic and risky.

On the network side, the project ships a LAN-only firewall posture by default: an nftables policy that exposes the web UI on 443 to private networks. In other words: private until you choose otherwise.

There’s also a guided first-boot setup flow that uses a one-time OTP, then creates the initial admin and can optionally enable 2FA, keeping onboarding straightforward without skipping basic safeguards.

How to try it, and what’s next

If you want to test-drive nOS right now, it’s designed to be uneventful in the best way: boot, run through first boot, and land in a UI that shows health, storage, and live activity quickly.

For contributors and tinkerers, the dev quickstart expects modern Go and Node toolchains and runs the API, agent, and web UI as separate dev processes. The roadmap energy is centered on foundations: the installer and first-boot experience, reliable update and rollback, the storage and health story, and tightening the operational UX so you spend more time using your services than maintaining the platform.

If this vision resonates, the best way to help is the boring, high-impact stuff: try it, break it, file issues, and share real-world constraints.

Repo: https://github.com/Nithron/NithronOS

‍

‍