Incus-Os: Immutable Linux OS to Run Incus as a Hypervisor
Posted2 months agoActiveabout 2 months ago
linuxcontainers.orgTechstoryHigh profile
excitedpositive
Debate
40/100
Incus-OSLinux ContainersVirtualization
Key topics
Incus-OS
Linux Containers
Virtualization
Incus-OS is an immutable Linux OS designed to run Incus as a hypervisor, sparking discussion on its features, comparisons to Proxmox, and potential use cases.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
9d
Peak period
62
Day 10
Avg / period
16.3
Comment distribution65 data points
Loading chart...
Based on 65 loaded comments
Key moments
- 01Story posted
Nov 5, 2025 at 4:39 AM EST
2 months ago
Step 01 - 02First comment
Nov 14, 2025 at 11:01 AM EST
9d after posting
Step 02 - 03Peak activity
62 comments in Day 10
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 18, 2025 at 2:45 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45821154Type: storyLast synced: 11/20/2025, 7:45:36 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
But this is definitely neat. I've found Incus quite handy for development environments, and a good compliment to docker.
The Incus server inside IncusOS is the same software. The difference is as little userspace as possible alongside it (not even busybox).
I use Proxmox on fat servers, but for homelab-like setup Incus OS seems more like a sweet spot
IncusOS does not give you shell access, you have to figure out IncusOS ways to do things via their CLI/API. I haven’t found an easy way to do incremental backup of the whole system yet. You can backup individual instances/volumes via incus export (which seems to use zfs send under the hood), but not the whole thing.
I have mixed feelings about their decision not to give you shell access. Guess those who want flexibility can always just install Incus on top of any Linux they like, but it would be nice to have an escape hatch for when IncusOS gives you almost everything you want…
My favourite example is OOM .. Linux will kill your docker container. SmartOS locks it up and makes it super hard to see understand why it failed.
I like smartos but I have painful memories from about a decade ago.
Incus however is what in use now in Linux.
The main filesystem is verified and immutable. Everything that isn't configuration or the user-controlled payload is genuinely read-only, and the system will even cryptographically verify it on boot or first use. You cannot modify /bin/bash, etc.
If you want to test a modification, you can configure an overlay, and you can boot with that overlay live. You can configure the overlay to also be immutable or you can make the overlay mutable. But the choice of booting into the overlay is controlled by code that cannot by overlaid, so you can always turn the overlay off no matter how much you screw it up.
The user may get root access, but if your system is remotely attested or uses a TPM or such for security, then that policy will find out if you do so before you can do anything as root. So you can shell in and attach a debugger to a system service, but you cannot do that and also pretend to your orchestration tools that you have not done so.
The default configuration is mostly empty. When you change a default, you are not modifying the middle of a giant plist where no one will ever understand what happened. You only create new configuration, and deleting it is just fine.
The result would, I think, give system owners plenty of ability to hack on their own systems, but they could also unhack their systems easily. There are very few systems out there with both of these properties right now...
I have noticed incus has better security configs by default. For instance, all pre-built images come with secureboot enabled and there are ACLs which are easy to configure for fine-grained network rules. The only downside I feel like is lack of something like PBS
I think their approach to authentication / authorization is insane (not in a good way).
https://github.com/lxc/incus-os/issues/496
https://github.com/lxc/incus-os/issues/497
IMO the client certs are pretty elegant from a technical perspective. It works well with the CLI, but the browser experience is different enough to cause at least some base level wtf-ery.
One thing in particular is permissions in unprivileged containers. In Proxmox, you have to do a bunch of somewhat confusing ID mapping. In Incus, it's as simple as setting "shift=true".
Also the profile system in Incus is really powerful and allowed me to deduplicate a ton of config.
LXD containers also are unprivileged by default.
The UID mappings are correctly setup in Ubuntu so the containers run non-privileged by default.
I hear Incus, a fork of LXD, is better. It’s used in truenas.
> The Incus project was created by Aleksa Sarai as a community driven alternative to Canonical's LXD. Today, it's led and maintained by many of the same people that once created LXD.
Thé confusion si real
It looks like it may handle networking (via ovn) a bit better than what I have now
There was a project to implement a dockcer-compose compatible "incus-compose" but unfortunately, it looks dead, right now.
You can even set up a kubernetes cluster entirely composed of containers: https://github.com/lxc/cluster-api-provider-incus
https://github.com/canonical/lxd it's AGPL-V3
So it's definitely still open source, but the changes they made allows them to still look and import any change from Incus that they wish, whilst preventing us from looking at any LXD code without risk of tainting ourselves...
https://discuss.linuxcontainers.org/t/introducing-incus/1778...
One of my favorite features is how you can tag different cluster members for different architectures. In the same cluster, I can have traditional dual-socket x86 servers with a dozen DIMM slots as well as Raspberry Pis. The architecture tagging lets me strategize execution of ARM-based container workloads to be only on the Pis, or opt to run them via QEMU on the x86 platforms if that makes more sense in a particular scenario. Since I deal with a lot of embedded firmware, this offers a nice, flexible platform.
Stephen Graeber is also a long time contributor to the LXC project and his reasoning behind this fork and other changes are quite sound. I hope the project sees continued success. Stephen’s business model of offering consulting services for Incus systems also seems quite sound.
I've filed https://github.com/lxc/incus-os/issues/551 which we should be able to sort out later today.
You can set your own Secure Boot keys. The history of outrageous security vulnerabilities that break it is long and storied. The underlying architecture is abysmal.
And finally, it suffers from hardcore tracking upstream, ie canonical/lxd(-ui), meaning they won't really do any changes that lxd wouldn't do, and thus are slaved to them : (
They try to not diverge unless "necessary", and for most parts it's not necessary to them.
The only time this held, vaguely to my recollection, true was prior to Incus 0.4 where both were cherry picking from each other but neither were upstream of each other
I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.
But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.
And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.
> I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.
This one is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example.
Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project)
As a whole, the project has left the choice of web interface up to the user: https://discuss.linuxcontainers.org/t/incus-6-7-has-been-rel...
> But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.
This is getting dangerously close to a mischaracterization of events surrounding the Linux Containers and Canonical split.
See: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde... in addition to: https://linuxcontainers.org/incus/announcement/
EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me.
> And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.
So far from my two years of interaction (both as a lurker and commenter) on the forums and purveyor on the issue tracker, I've yet to see anything that resembles treating Canonical LXD as any form of upstream especially since the split.
The Incus teams are low level system engineers who develop in Go or C. The UI is a pile of typescript which none of us really want to understand/touch any more than strictly needed.
The Incus UI is a soft fork (really just a small overlay) on top of the LXD UI to adjust for the API differences between LXD and Incus and for fixing the few big gripes we had with the LXD UI. Because both projects are under the same license, we can actually just follow what happen in LXD UI and pull in code from it.
Incus is a very different beast. The whole reason the project had to be started is because of Canonical's series of changes which eventually led to a re-licensing of LXD to AGPLv3. With Incus remaining Apache 2.0, none of us can even look at the LXD code without risking being "tainted". We cannot import any code from LXD since that license change and we never have. However LXD has no problem with importing Apache 2.0 code into an AGPLv3 codebase, which they have quite actively been doing.
In short Incus is a hard fork of LXD, we don't look at any LXD code or even at their issues or release announcements (mostly because it's not useful for those two). That means that everything that happened in Incus since December 2023 has been completely independent of LXD.
The Incus UI is a soft fork of the LXD UI, it's rebased every time they push a new version out and our goal is to keep the delta as small as possible as it's something we want to spend as little time on as we possibly can. It's also why we always package it as "incus-ui-canonical" to make it very clear as to what it is.
There are also other UIs out there that could be used, sadly last I checked none came close to the feature coverage of the LXD UI or they had dependency on external components (database, active web servers, ...) whereas what we want is a UI that's just a static javascript bundle which then hits our REST API like any other client.
Most of the maintainers and contributors to LXD have moved to maintaining and contributing to Incus instead because it is community-oriented. Incus also has a lot of features LXD doesn't have (list is too long to enumerate, but one notable one is support for OCI images is Incus-exclusive).
Stephane was arguably the primary maintainer of LXD before the split and how now exclusively works on Incus. AFAIK the only LXD-related thing that is still shipped by Zabbly is the LXD web-ui (which I get the impression Stephane doesn't feel is worth maintaining separately since it's easy to just swap out the branding -- which is what he does). Ultimately an optional web-ui is not a particularly large part of the project...
(To be honest, I only learned about the web-ui when someone asked I package it for openSUSE a few months ago. Maybe I would've forked it too back when I forked Incus if I knew about it, though I'm not a web dev.)
However, I'm confident that if that is what you want, this is probably fantastic — Incus, including the old LXD (which was mainly built by the same core developers, until Canonical behaved in ways they didn't like, and they hard-forked LXD to create Incus) has been one of my favorite open-source projects for several years.
Fantastic software, steady stream of reliable releases, helpful community... Incus is great.
It doesn't. You can still run Incus on other platforms of choice.
Sample size 1 here, but a big advantage of the 'full-stack' approach is things like network config, storage management, boot safety etc all work out of the box and you then get a single API (and nice client) for the whole machine. I get the benefits of cloud infra, like not having to care (too much) about sysadmin, from some hardware sitting in the corner.
I can literally
and start hacking.Previously I would still need to be maintaining that base layer too. That still makes sense for some environments, but particularly for home I just want my lights and music to work, and be able to play.
I run instances I need to interact with (e.g., do development in containers via SSH and remote-editors, with occasional Remote Desktop) on my very-fast Linux workstation — that also does other stuff like local development, web browsing, etc., but most instances that don't need power run on my old 56-core Xeon enterprise server (used, they are roughly as cheap as a Mac Mini).
Incus makes it super easy to move instances around, and from a skim of the announcement it looks like you could just put Incus OS on some machine you have lying around and drop it into an existing config like that with minimal effort.
I look forward to trying it out, even if my "main" Incus will probably remain on my actual manually-curated Linux desktop.
Because both my project and Incus are written in Go, orchestrating Incus resources in my test code has been pretty seamless. And with "ephemeral" containers, if things start to get out of hand, I just need to stop the container to clean it up. Much easier than a 2-step process like it usually is.
Looking forward to seeing what's to come in IncusOS!
4 more comments available on Hacker News