openwrt-iac / uapi / docs / 1.2.1 / Non-uci state: what uapi covers and what it doesn't

Non-uci state: what uapi covers and what it doesn't

uapi's design contract is "uci is the source of truth". Almost every resource translates HTTP REST verbs into uci_set / uci_commit followed by a daemon reload. That model covers most of OpenWrt's configuration surface, but not all of it. This document inventories the small set of state that lives outside uci, in two categories:

  1. In-scope, non-uci resources. Things uapi exposes anyway, with deliberately documented deviations from the standard transaction recipe.
  2. Out-of-scope state. Things uapi explicitly does NOT cover, with the recommended out-of-band path for each.

The bar for adding to category 1 is high. New non-uci resources should justify themselves against three questions: is the underlying daemon's uci surface genuinely missing this? would the right long-term fix be to add a uci option upstream rather than carry workaround state in uapi? does the resource fit a curated CRUD shape, or is it a one-shot action better handled by an operator tool?

In-scope non-uci resources

The canonical registry (and the single-line table form) lives in CLAUDE.md under "Resource model" → "Non-uci resources". Each entry below expands on its lock semantics, audit shape, the file/process it touches, and why the standard uci-transaction recipe doesn't apply.

packages/installed

packages/feeds

dhcp/leases (read-only)

dhcp/leases6 (read-only)

system/password (write-only)

system/authorized_keys

Out-of-scope state

The following items are real configuration concerns that uapi deliberately does NOT cover. For each, the recommended out-of-band path is listed. An IaC orchestrator typically wires these once at image-bake time (cloud-init / /etc/uci-defaults/) rather than reaching for them on every reconcile.

Unbound listen-address binding

Serial console / inittab

Wake-on-LAN packets

Certificate regeneration via px5g_x509

FreeBSD sysctl tunables from an OPNsense-style migration

RRD / NetFlow history

When you find a new gap

If your real-world configuration needs something uapi can't currently express, the first question to ask is: does the underlying OpenWrt package expose this via uci? If yes, the curated resource is undercurated; file an issue. If no, the right fix is usually to upstream a uci option, not to add another non-uci resource to uapi.

If, after weighing those, a new non-uci resource really IS the right answer, it needs to ship together with: