IncusOS + NetBird: safe pattern for core.https_address / cluster.https_address

IncusOS
,
1

Hi,

I’m running IncusOS and joining nodes to an Incus cluster where I want all admin/API + cluster member traffic to go over NetBird (no public IPs, ideally no inbound firewall rules on WAN). I am using incusOS version 202604261712.

What I am doing

  • IncusOS nodes use the NetBird service for connectivity.

  • NetBird comes up as wt0 with address (e.g. 100.x/…) and DNS names under our NetBird domain.

What I’m trying to achieve

  • Security / simplicity: avoid exposing :8443 on public interfaces; keep management on the overlay. All my infrastructure is already managed by netbird.

  • Interoperability: join cluster members that don’t have stable public IPs.

What confuses me in IncusOS networking UI/config

  • In IncusOS system network configuration, the NetBird interface (wt0) does not appear, so I cannot assign roles like management / cluster to it.

  • Separately, I’m trying to set Incus to listen/advertise on NetBird using:

    • core.https_address

    • (and if applicable) cluster.https_address

    • (and if applicable) Make communication between IncusOS and OperationCenter over netbird too

Failure I encountered:

I set core.https_address to a NetBird DNS hostname (FQDN). After reboot, Incus tried to bind before NetBird/DNS was ready, and the node became unreachable on both public and NetBird.

Questions

  1. What is the recommended pattern on IncusOS for making Incus API/cluster traffic prefer NetBird without racing NetBird startup?

  2. Is there an IncusOS-supported way to model NetBird in system network config (roles, ordering, dependencies), or is wt0 intentionally out of scope for system network roles?

  3. For clustering specifically: is using NetBird DNS names for member reachability considered good practice, and are there known pitfalls with certificate SANs or split DNS preference on management selection?

2 Likes