https://discuss.linuxcontainers.org/t/announcing-incusos/25139 Linux Containers Forum Announcing IncusOS News release, incusos stgraber (Stephane Graber) November 7, 2025, 3:38am 1 Introduction After a bit over a year of hard work, the development team is very excited to announce general availability of IncusOS! image image1280x800 6.8 KB IncusOS is a modern immutable OS image that's specifically designed to run Incus. It provides atomic updates through an A/B update mechanism using distinct partitions and it enforces boot security through UEFI Secure Boot and a TPM 2.0 module. Under the hood, it's built on a minimal Debian 13 base, using the Zabbly builds of both the Linux kernel, ZFS and Incus, providing the latest stable versions of all of those. We rely a lot on the systemd tooling to handle image builds (mkosi), application installation (sysext), system updates (sysupdate) and a variety of other things from network configuration to partitioning. It's a very locked down environment where no local or remote shell access is provided. The entire system is configured and operated through the Incus API, using either TLS client certificate authentication or external OIDC authentication. An introduction video can be found here: [3d094d8916bd3cb66c705fddbc2bb005ab509ce2] Website: Linux Containers - IncusOS - Introduction Documentation: IncusOS documentation Github: GitHub - lxc/incus-os: Immutable Linux OS to run Incus How to try it IncusOS is designed to run on bare metal, mostly on modern servers from the past 5 years or so. But it can also run on some older hardware so long as they meet our minimum requirements or it can be run in a virtual machine, mostly for testing purposes. We've published detailed instructions for a variety of environments here: [7ae] IncusOS documentation [47bf76177a696627ba10a23cc6cc062b1ae4c953] Installing IncusOS IncusOS is designed to run on modern physical hardware as that's the optimal environment to run an Incus server. But we also support having it run inside of a virtual machine, making it easier to e... Downloading IncusOS is most easily done through our online image customizer which allows for selecting the desired image and behavior as well as providing the public certificate to be trusted upon installation. A custom image is required as there is no interactive installation process at all. Everything needed for installation and initial startup is defined through built-in configuration (referred to as seed) which gets applied to the system on first boot. Additionally, all Incus online demo sessions have been using IncusOS for the past 3-4 months now. What's next Now that IncusOS is considered stable, we will be producing at least one stable build a week to pick up the latest Linux kernel bugfix release and any other Incus or Debian bug fixes. We also still have quite a few features and improvements to make to IncusOS, this ranges from adding a few more configuration options to adding support for Linstor (alongside the existing Ceph support) and more system services like Netbird (alongside our existing Tailscale support). On the more exciting front, we're working on a couple of changes to both IncusOS and the Incus UI to allow full deployment and management entirely through the web interface, also eliminating the need for TLS client certificate authentication: github.com/lxc/incus-os Offer public OIDC based authentication as alternative to TLS opened 03:14AM - 07 Nov 25 UTC # stgraber To make installing easier for folks who prefer using the web UI over the CLI, it...'d be great to not have to mess with TLS client certificates. In order to do that, we'll stand up a public OIDC server at https://sso.linuxcontainers.org which will support a variety of external authentication providers as well as local accounts and will provide a generic application (client id) which can be used with any Incus installation. It's worth noting that this will require the application definition in the IdP to allow effectively all redirect URLs. This is usually seen as problematic when it comes to OIDC configs, but for this particular use case, there is no real alternatives and it shouldn't really be a problem given that IdP will only hold minimal user information and won't support any application other than Incus itself. The end result will be that the user will now be able to: - Download an installation image that doesn't include a TLS certificate but instead includes a list of trusted users (e-mail addresses) that will be provided with full admin access on the deployed system - Post installation, the user will be able to go to https://:8443 and will get prompted for SSO login - This will bring them to https://sso.linuxcontainers.org which will have them login either through an external identity provider (Google, Microsoft, Github, Gitlab, ...) or using a local account - The IdP will require them to set up a secondary factor for authentication - And finally, they'll be able redirected back to the Incus UI with full admin privileges This combined with the work from https:// github.com/zabbly/incus-ui-canonical/issues/90 should allow for installation, configuration and operation of IncusOS entirely from the web UI. More advanced setups like clustering will still require the CLI to be fully set up, but for someone who just wants to run a simple virtualization server, they'll be able to do it without touching the CLI. github.com/zabbly/incus-ui-canonical Implement an IncusOS management page opened 03:04PM - 06 Nov 25 UTC # stgraber When running on top of IncusOS, it would be good for the UI to be able to manage... the system itself. For that we should: - Add an `OS` section in the menu (I'd put it after another horizontal bare below Settings) - Have that page support selecting the server you're trying to manage (when clustered), probably with a drop-down at the top of the page, similar to what we have for cluster groups in the cluster page - The page itself should have tabs for: - Overview (show version, show update status, show installed applications with versions, button to trigger update check, buttons for shutdown/ reboot) - Log (show current systemd log) - Network (show current network config and state, allow editing the network config) - Storage (show current storage and state, allow editing the storage config) - Security (show current security state, allow editing config) - Services (show the list of services, allow expanding the state and update the config of each) Once that's all sorted out, we'll focus on supporting an automated deployment of the full Incus stack including all recommended support services (authentication, authorization, monitoring, distributed networking, distributed storage, ...). github.com/lxc/incus-os Offer a full Incus deployment as part of Incus initialization opened 03:29AM - 07 Nov 25 UTC # stgraber Currently IncusOS makes it easy to get Incus up and running, including some basi...c initialization, giving users an initial network and storage pool for their instances. But to provide the full Incus experience, we'd ideally like to also provide: - An OIDC identity provider (Zitadel, Authentik, Keycloak, ...) - An OpenFGA instance for authorization - A Loki server for logging - A Prometheus server for Incus and system metrics - A Grafana server for dashboards (integrated with OIDC for login) - A reverse proxy (haproxy, traefik, ...) to front everything This would be all be optionally deployed as part of initialization within an `internal` Incus project and attached to a VXLAN network, making it easy to eventually span this to multiple systems within a cluster (without requiring VLANs or other complex network configuration). In addition, that same `internal` project could be used to deploy: - Linstor controller - Ceph services (OSD, MON, MGR, MDS, RGW, ...) - OVN services (OVSDB for NorthBound, SouthBound, northd, IC databases, ...) To make this easy to deploy and manage, we should try to have all of those deployed from OCI images with IncusOS being responsible for generating an initial configuration (environment variables mostly) and then offering the ability to update them by re-building them from the latest version of their respective image. This would then provide the full Incus experience, all deployed safely on top of IncusOS and with minimal user maintenance required. (Once we manage to sort all of this one, the next step will be to handle easy clustering, making it as simple as possible to go from a single Incus server with all the aforementioned services to a cluster of 3+ machines with those services getting automatically spread over them) How can you help At this point, we'd love for as many as possible to give IncusOS a try, both in a virtualized test environment and on any spare physical hardware you may have. Just keep the Secure Boot and TPM 2.0 requirements in mind. A general rule of thumb is that any piece of hardware capable of running Windows 11 will also be capable of running IncusOS. We have opened a new forum category for questions and discussions around IncusOS: IncusOS Discussions about IncusOS, our immutable OS image build from the ground up to run Incus. Bugs and feature requests can be filed directly on Github: [fav] GitHub [5fb7a3e1f4c3b7be374e0594f61ec2ad4a314b59_2_690x345] lxc/incus-os Immutable Linux OS to run Incus. Contribute to lxc/incus-os development by creating an account on GitHub. 25 Likes Incus homelab guidance stgraber (Stephane Graber) Split this topic November 9, 2025, 6:53pm 3 3 posts were split to a new topic: Security requirements and running in the public cloud stgraber (Stephane Graber) Split this topic November 9, 2025, 7:02pm 5 A post was split to a new topic: Firewalling in IncusOS stgraber (Stephane Graber) Split this topic November 10, 2025, 3:06am 6 A post was split to a new topic: RAID-1 for boot drive * Home * Categories * Guidelines * Terms of Service * Privacy Policy Powered by Discourse, best viewed with JavaScript enabled