I’m excited to share the open beta launch of CTRL-OS, a NixOS LTS solution that we’ve been working on at Cyberus Technology.
The Problem We’re Solving
Many of us love NixOS for its reproducibility and declarative configuration management, but the 6-month release cycle can be challenging for enterprise environments that need long-term stability. This becomes especially critical with regulatory requirements like the upcoming Cyber Resilience Act (CRA) deadline in January 2027, which demands maintaining cybersecurity throughout a product’s entire lifecycle - including all open-source components.
What is CTRL-OS?
CTRL-OS bridges this gap by providing NixOS long-term support while preserving everything we love about the NixOS approach. Built on NixOS 24.05, we’re building:
CRA Compliance Features
Vulnerability tracking and security patch management
Complete software bill of materials (SBOM) generation
Streamlined compliance reporting and audit trails
Pre-configured security baselines for certification use-cases
5-Year long-term Support
Security backports and critical updates for NixOS 24.05 (and 26.05 next year)
Predictable maintenance windows with rollback safety
Enterprise SLA with dedicated support channels
Technical Excellence
All the NixOS benefits: reproducible builds, atomic upgrades/rollbacks, declarative configuration
Modular, certification-friendly architecture
Perfect for embedded systems, medical devices, industrial control systems
Target Use Cases
CTRL-OS is specifically designed for:
Embedded systems requiring long-term support and compliance
Medical device infrastructure with regulatory requirements
Industrial control systems needing extended stability
Open Beta Program
We’re looking for organizations to participate in our beta program. Beta participants get:
Early access with hands-on engineering support
Direct influence on feature development and package prioritization
Migration assistance from existing NixOS deployments
Disclaimer: I’m a Co-Founder of Cyberus Technology. We’re committed to contributing back to the NixOS ecosystem and maintaining transparency in our enterprise offerings.
Congratulations on your launch! While I have no need for it(being a personal user only who runs nixpkgs-unstable lol), this seems like a great addition to the nixpkgs ecosystem. How does this work, though? Are you doing a similar workflow to current backports, where you take commits from nixpkgs’ master branch and cherry-picking them to your own, creating your own commits of changes from nixpkgs, or something else? Would love to understand how you’re doing this, thank you!
i see in your docs that you publish channels and have a cache… it appears to me to be completely open - very cool!
i have to assume there is a subscription fee coming… i just didn’t realize this would be wide open at this point - are you able to clarify roughly at what point these channels will be no longer be publicly available? i am mostly just curious and might play around with them at some point
There is mention that the SBOM-generation tool can also be used to tell them which packages are actually in use, with the implication that their support set will be guided from there. Which is both a neat idea and essentially confirmation that this is evolving scope.
Are you doing a similar workflow to current backports, where you take commits from nixpkgs’ master branch and cherry-picking them to your own, creating your own commits of changes from nixpkgs, or something else?
Since our support model is a bit different from what is done with the current backports we are not cherry-picking but creating our own commits. We are providing patch updates for software that is packaged in 24.05.
This is easiest to explain if you imaging a software following the semver versioning model with a MAJOR.MINOR.PATCH versioning. For CTRL-OS we will default to providing PATCH updates and might provide MINOR updates in some cases. But we will generally not do MAJOR updates.
i have to assume there is a subscription fee coming… i just didn’t realize this would be wide open at this point - are you able to clarify roughly at what point these channels will be no longer be publicly available?
We are planning to provide public channels and cache with updates to the release-small set at least until the next release (26.05). After that our plan is to provide a public channel and cache for 26.05, but only provide updates for 24.05 to our paying customers.
Since I assume you are not going to support all packages in nixpkgs for 5 years, are you still trying to figure out what the scope will be?
There is mention that the SBOM-generation tool can also be used to tell them which packages are actually in use, with the implication that their support set will be guided from there.
As noted above we provide updates to the release-small set and customers can pay us to support additional packages (e.g. by providing us with an SBOM).
Both Debian and RedHat maintain and patch software for their repositories when there’s security issues, will you do something similar? Have you thought about tracking Debian/RH LTS release sources where applicable?
I think that’s the intention: provide patched software for their consumers so they can stay on 26.05 for 5 years, instead of 0.5 years.
I’d strongly advise against this. Primarily because Debian doesn’t have a stable release that will match the software versions in nixpkgs 24.05 so many packages will need to be downgraded. As for RedHat, the same version downgrade argument as Debian applies here, plus one would need to fetch sources from CentOS Stream, not proper RHEL due to their post-IBM-acquisition stances.
EDIT: Additionally, there are usually instances (especially with RHEL) where they aren’t consistent in their method of patching. Sometimes the source tarball is generated from their internal git repo with patches already applied and other times they ship a patches as individual patches.
As I told you already, I’m personally very interested in an LTS (desktop oriented though) and I’d love to see a communautary effort around this. Will you be open to have a public branch, not necessarily for the full 5 years duration, but for instance 2 years?
I think it’ll be very valuable to everyone, because the community could enjoy a longer maintained branch for those who prefer that, and you guys would enjoy more workforce.
This would not undermine the value you provide in my opinion, which has more to do with all the CRA compliance features as well as the direct support than commits upgrading packages.
Anyway, it’s a nice addition to the nixos ecosystem and much needed in enterprise environment!
The closure produced by nixpkgs/nixos/release-small.nix is pretty minimal, I think. And its point isn’t to really have fully usable sets of binaries in it, more like run a few basic NixOS tests quickly, so that we can prevent at least the worst breakages from reaching the *-small channels. And people’s servers can build whatever is missing if they update early. (mainly in case of hurrying to fix some security issues)
Yes, I fully agree. And we’d be very open to work with the community to define a better minimal set of packages. We decided on using this set, because we needed something to get started.
CRA Compliance Features
5-Year long-term Support
Technical Excellence
