Architecture
A two-tier fleet you treat as one machine
One Primary runs the operator-facing panel and mirrors the whole fleet. Any number of Secondaries run the roles you assign and report state back. Understand the model in ten seconds, then scale it as far as you like.
The two tiers
Primary: the panel host
Secondaries: the workload hosts
Adding a host
A secondary joins in one line
Point the installer at the register URL the Primary gives you. The box installs itself, registers, and starts reporting. There is no key to copy onto it and nothing to mount.
$ wget -qO- https://unicornpanel.com/install | sh -s register <register-url> More on fleet management.
The building blocks
Small pieces, predictable behavior
One daemon per host
A single small daemon does the privileged work on each host, so the panel itself never needs the run of the machine. It is the same binary everywhere, with nothing to assemble per server.
A container per site
Every site gets its own container, its own user, its own ports, and its own limits. Nothing is shared between tenants, including PHP-FPM.
No central database
Each host keeps its own state. There is no shared database in the middle to scale, tune, or lose, and no cluster to stand up before your second server.
The panel stays in sync
Every action on a peer’s resource echoes back to the Primary, so the panel’s view keeps up as things change. Health, CPU, and memory poll on a schedule.
API keys between hosts, not SSH
Each host holds its own key with its own scope. The Primary reaches a secondary over HTTPS with that key, and the secondary answers only the calls it recognizes. No shared root SSH key, no agent forwarding, no shared filesystem.
Built on Alpine Linux
A small base and a fast boot, built for both amd64 and arm64, so the same panel runs on a rented server or on Ampere and Graviton hardware.
No usage telemetry
Your operator data stays on your servers. What reaches us is a count of servers and accounts, so the invoice can follow your fleet, and nothing about the sites on it.
Fails soft, not shut
The license check runs when a key changes, on upgrade, and when a role is installed, not on every request. If we are unreachable it keeps working for 30 days, and your customers see no difference.
Why this matters
Multi-server as the foundation,
not a feature flag
Most panels were built for one box and had multi-server added later, which is why it so often means a second install, a shared database, or a paid add-on. Here, Primary and Secondary is how the product was built. Every host is a first-class object the panel can provision, monitor, reach into, and roll upgrades across.
Because each host keeps its own state and the Primary mirrors it, there is no shared database to become the bottleneck as the fleet grows. Add a secondary with one command, assign it roles, and it starts reporting. Retire it when you are done with it.
The same model carries the reseller story: a reseller is given a slice of the fleet to sell, under their own brand, and their customers only ever see their own sites.
Scale out without scaling your headaches.
One Primary, any number of secondaries, no central database, and no usage telemetry.