What UniFi Reactor is

Your WAN fails over to the 5G backup at 3am. Nothing in the cluster notices: qBittorrent keeps seeding, the nightly backup starts on schedule, and you find out when the data cap bill arrives. Or the power drops, the UPS starts counting down eighteen minutes of battery, and your cluster spends them transcoding video.

Your UniFi gear already knows all of this. UniFi Reactor is a Kubernetes operator that turns what it knows — which WAN is live, whether the UPS is on mains — into declarative actions on your cluster.

Why this exists

• State, not events — Reactor polls the UniFi Network API and reconciles against what it observes. A dropped webhook, a network blip, or a controller restart can’t strand your cluster in the wrong mode, because the next observation corrects it. Webhooks are an optimization, never the mechanism of record.
• Reversal is explicit — an automation says what to do when a condition starts holding, and separately what it wants once it stops. Nothing is inferred, undoing is never guessed, and every execution is recorded in the resource’s status.
• One workload, many automations — a target’s level is arbitrated across every automation pointing at it, not written by whichever one saw a transition last. Two automations can pause the same workload for unrelated reasons, and it stays paused until neither wants it down.
• Safe by default — a dedicated ServiceAccount with exactly the verbs it needs, no cluster-admin, no arbitrary shell execution, and credentials read from Kubernetes Secrets. Scaling is desired-state (replicas = 0), so retrying it is harmless; the actions that leave the cluster are refused until you say where they may go.
• Boring to operate — one static binary in a distroless image, no database, no queue, no UI. Small enough to forget about in a homelab.