LXC/Incus system containers: what they are and when to reach for one instead of an application container

What it is

Incus, documented at linuxcontainers.org and forked from LXD in 2023, is a manager for system containers and virtual machines, both handled through the same "instance" abstraction and command set. Its documentation describes a system container as one that runs a full operating system, complete with an init system and multiple services, rather than a single application — the model LXC popularized and Incus continues. Application containers (Docker/Podman's usual model) instead package one process and its dependencies, typically without an init system inside.

Why it matters

The two models suit different jobs. A system container behaves like a lightweight, fast-booting VM: you can ssh into it (or use its console), run several long-lived services inside, apply OS package updates inside it, and treat it much like a small dedicated machine — while sharing the host kernel, so it typically starts within seconds and uses less overhead than a full VM. (An SSH login needs an SSH server installed inside, like on any machine.) An application container is built for one job per container, orchestrated and replaced as a unit, with state pushed outside it. Choosing a system container to run one web server process adds complexity a Podman/Docker container would handle more simply; choosing an application-container engine to host a full multi-service legacy environment fights the tool's assumptions.

How to apply

• Access: the incus client needs root or membership in the incus-admin group for full control of the local server (the incus group gives a restricted per-user project).
• Create and inspect an instance: incus launch images:debian/12 mycontainer starts a system container from a published image (add --vm for a virtual machine); incus list shows all instances and their type, state and addresses.
• Get a shell: incus exec mycontainer -- bash runs a command inside; incus console mycontainer attaches to the instance console (useful before networking is up; detach with Ctrl+a q), and incus console mycontainer --show-log prints its console log.
• Snapshot before a risky change: incus snapshot create mycontainer before-upgrade, then incus snapshot restore mycontainer before-upgrade to roll back. As with any snapshot, it lives on the instance's own storage pool, not as an independent backup; for that, incus export mycontainer /backup/mycontainer.tar.gz writes a tarball you can move to other storage.
• Use Incus (or LXC directly) when you want an OS-like, persistent, multi-service environment sharing the host kernel; use Podman/Docker when the unit of deployment is a single process built from an image.

Pitfalls

• Assuming a system container is a security boundary equivalent to a VM: it shares the host kernel, so kernel vulnerabilities affect isolation the way they do for any container technology. Containers are unprivileged (UID-mapped) by default; setting security.privileged=true removes that mapping and should be avoided for untrusted workloads.
• Running unattended package upgrades inside many system containers without the same patch discipline used for the host — each one is a small OS that needs its own maintenance.