Unifi

A site with multiple UniFi access points and other supported devices needs a central place to configure and manage them. The UniFi Network application provides that management service, tracking adopted devices, sites and network settings. This historical resource packaged it through a community Kubernetes chart. Current vendor self-hosting guidance uses a different hosting model, so a move must preserve device connectivity and adoption as well as the web interface, with the correct backup type for the chosen target.

Current guidance

The recovered entry is a community Kubernetes chart for the UniFi Network Controller, now generally called the Network application/server. Ubiquiti’s current self-hosting guidance identifies UniFi OS Server as the newer standard and provides a migration path from the legacy Network Server. Ubiquiti explicitly says UniFi OS Server is not offered as a standalone Docker/Podman container because it requires services on the host for device discovery, adoption and system updates. Verify the exact supported host platform and application version before choosing a third-party container or chart.

Network management depends on device adoption, inform addresses, site configuration and reachable management ports, not just a web UI. A move between hosts or hosting models can change those addresses and, according to the current guide, captive-portal ports. Keep administrative access separate from the network paths devices need to communicate with the controller.

Create the appropriate Network backup or site export and retain device recovery credentials securely. Rehearse restore on the target, then verify that devices reconnect, configuration is retained and guest-portal behavior works before decommissioning the old instance. Avoid having two controllers compete for the same devices. Distinguish a full-system backup from a Network-only backup; they are not interchangeable for every UniFi console or application.