Skip to content

Advanced Incus usage

This page collects advanced patterns that are useful after the basics are comfortable.

Projects for isolation

Use separate projects for risky labs:

incus project create security-lab
incus project switch security-lab

Set limits:

incus project set security-lab limits.instances 10
incus project set security-lab limits.memory 16GiB

Nested containers or Docker inside Incus

Running Docker inside an Incus instance is possible but should be deliberate. Prefer a VM for Docker-heavy workloads when isolation matters.

For a lab container that needs nesting:

incus config set docker-lab security.nesting true
incus restart docker-lab

For safer production-like Docker hosts, use an Incus VM instead:

incus launch images:debian/13 docker-vm --vm

GPU or USB passthrough

List devices on the host first:

lspci
lsusb

Add a GPU device example:

incus config device add gpu-vm gpu0 gpu

USB example:

incus config device add test-01 usb0 usb vendorid=1234 productid=5678

Hardware passthrough is host-specific. Document the exact device IDs and rollback plan.

Proxy devices for services

Expose an HTTP service from an instance:

incus config device add app-01 http proxy listen=tcp:127.0.0.1:8080 connect=tcp:127.0.0.1:80

Use 127.0.0.1 when another host-level reverse proxy will publish the service.

Use 0.0.0.0 only when you intentionally want all host interfaces to listen:

incus config device add app-01 https proxy listen=tcp:0.0.0.0:443 connect=tcp:127.0.0.1:443

Security options

Inspect current security-related config:

incus config show app-01 --expanded | grep -E 'security|raw|privileged' || true

Avoid privileged containers unless you know why you need them:

incus config set app-01 security.privileged true

If a workload needs many elevated permissions, use a VM instead.

Cluster awareness

Incus supports clustering, but a cluster adds operational complexity.

Useful commands on a cluster:

incus cluster list
incus cluster show <member>
incus list --all-projects

Cluster planning needs:

  • reliable networking;
  • shared or replicated storage strategy;
  • clear upgrade procedure;
  • tested backup and restore;
  • monitoring.

API and automation

The CLI is the best daily interface, but Incus also has an API. For automation:

  • prefer idempotent scripts;
  • check whether instances exist before creating them;
  • make names, IPs, images, and resource limits configurable;
  • log every destructive action;
  • snapshot before risky changes.

Example safe create pattern:

if incus info app-01 >/dev/null 2>&1; then
  echo "app-01 already exists"
else
  incus launch images:debian/13 app-01
fi

Advanced rule of thumb

If a setting weakens isolation or touches host hardware directly, document why it is needed and prefer a VM unless a container is clearly appropriate.