SecureGuard ships as a whole appliance image, not a package you add to an existing operating system. The image owns the disk: FreeBSD 14.4-RELEASE base, ZFS on root, the orchestrated daemons, and SecureGuard's own control plane.
Requirements
| Item | Minimum | Notes |
|---|---|---|
| Architecture | x86-64 (amd64) | Physical or virtual |
| Disk | One disk, erased | ZFS-on-root takes the whole device. The image is 6 GB; give it more. |
| Interfaces | Two | One WAN, one LAN. A third is needed for a dedicated HA link. |
| Memory | 4 GB | ZFS plus Suricata is the driver. More if you enable the proxy. |
| Console | Serial or video | Needed for the first-boot network setup. |
Virtual deployments, if you will ever cluster: HA failover reprograms interface MAC addresses, so the hypervisor has to permit it. On VMware/ESXi set MAC address changes and forged transmits to Accept on the port group; on Hyper-V enable MAC address spoofing on the adapters. Without those the takeover frames are silently dropped by the virtual switch and failover looks like a black hole.
Get the image
Images are published in your account alongside your licenses. A release is a signed system image — a ZFS stream of the root boot environment, containing the whole OS and all SecureGuard code but not your configuration or state. Install media and online updates consume the same image, so a freshly installed node and an upgraded node are byte-identical.
Write the raw disk image to the target disk with whatever you normally use for that. Boot it, and it expands into its ZFS layout: one bootable root dataset plus two shared datasets that survive every future upgrade — /cfg for configuration revisions and secrets, /var for leases, logs and state.
Status: Hub publishes public ISO and USB installer media for SecureGuard 1.1.170. Install media and online updates consume the same signed system image. Build status. If you are deploying now and need a fit check — describe the network.
First boot and the node ID
On first use the appliance generates a device ID — a UUID — and persists it at /cfg/device-id. Because /cfg is a separate dataset, that ID is stable across reboots and OS upgrades but unique per install. This is the node ID you give the activation page: a license carrying it activates only on this appliance.
It is shown during setup and on System ▸ License in the console.
Two different things are called "node id". The license binding is the device ID at /cfg/device-id. Separately, an HA pair records which box is node 1 or node 2 at /var/db/rubix/node-id — a local fact deliberately kept out of the synced config document. Activation wants the first one.
Then activate
- Request an activation code — Get a free license, or checkout for a paid plan.
- Install the appliance and read its node ID.
- Give the code and node ID to the activation page; you receive the key.
- Paste the key into System ▸ License. Entitlements apply immediately — no reboot, no commit.
The appliance can also redeem a code itself, headlessly, against the redeem endpoint. Either path is idempotent: the same code and node ID return the same key and do not consume another seat. Licensing reference.
Upgrades that can back out
Because the root filesystem is ZFS, an upgrade is a boot environment rather than a file-by-file replacement, and rolling back is a reboot.
- Verify before touching disk. A release is delivered as an upgrade bundle containing a manifest, the system image and a signed checksum list. The appliance verifies the signature and the image checksum, fail-closed, and rejects a mismatch before anything is written.
- Receive into a new environment. The image lands in a new root dataset. The running system is untouched, so a failed upgrade cannot brick the box.
- Activate for next boot only. A one-shot activation plus a pending marker, then a reboot.
- Confirm or fall back. First boot runs a health check — configd healthy, its socket up, pf loaded, an active revision present. Healthy makes the new environment permanent; unhealthy, or no confirmation inside the watchdog window, and the next reboot lands back on the environment that was working.
Bundles can be pulled from a CDN manifest URL or uploaded by hand at System ▸ Upgrades. Two independent safety nets exist and they compose: a bad image rolls back via the boot environment, and a bad config rolls back via the commit engine's confirm window. How that window works.
In testing: cluster-aware rolling upgrade — upgrade the passive node, fail over, then upgrade the former active — is designed. HA itself is tested and shipping; the rolling upgrade path is not confirmed end to end.