Skip to main content

Networks and profiles

By default, kixctl owns the fabric its deployments run on. On first use it creates and owns a bridge (kixbr0), a profile (kix, a root disk only), a CoreDNS resolver, and a Caddy edge — all on that owned bridge. Every instance it launches, including a git push deploy, rides the owned network and profile and is reachable through the owned edge, never your LAN or existing bridges unless you choose otherwise.

The rule is consistent everywhere kixctl manages infrastructure: it opinionates what it owns and integrates with what you own. Self-containment is the default; your existing bridge, profile, or resolver is always available as an option, and every owned-versus-existing choice defaults to owned.

Managed and unmanaged​

Every network and profile kixctl shows is one of two kinds:

  • Managed — kixctl created and owns it, and can change it. A managed network's NAT and DHCP are editable in place; because an Incus configuration change is a merge, a live edit preserves the subnet rather than resetting it.
  • Unmanaged — a reference to something you created, which kixctl records but structurally never mutates. Registering your existing bridge lets kixctl place instances on it and show it, with no risk that the tool alters a network backing live instances. Host-created networks are read-only by design.

The Network tab​

Under Settings → Network, kixctl creates, registers, updates, and deletes managed networks, sets the default, and returns to its owned defaults. Writes are managed-only and bridge-first; a network you registered is immutable through kixctl. Network writes are synchronous — Incus returns a normal response, so there is no operation to wait on.

The Profiles tab​

Settings → Profiles follows the same locked-default, managed-or-unmanaged pattern; the owned kix profile is locked. Editing a profile definition sends only the curated configuration and never the devices map — omitting the devices makes Incus preserve every device already attached, which is what makes editing a widely-inherited profile safe. A profile edit has the widest blast radius of any change, because it touches every instance that inherits the profile, so profile.update is an admin-tier permission.

Reaching deployments by name​

A deployed app becomes reachable at a stable <app>.<zone> name through the owned resolver and edge — the managed ingress provider, which rewrites one DNS zonefile per deploy and needs no edge restart. The manual provider is the alternative: kixctl writes no DNS, the Ingress settings surface each app's target, and you point your own resolver at it. Getting those names to resolve and route from your wider LAN is covered in LAN reachability.