PRODUCT
Zyvor Fleet
Offline-first edge fleet control plane for Linux, Kubernetes, containers and virtual machines.
-
Tutorial
A hands-on walkthrough: stand up a demo fleet, tour the web console, declare desired state, and promote your first rollout.
-
Deployment guide
Systemd, Docker Compose, and Kubernetes/Helm install paths, plus the production checklist to run before go-live.
-
Lab stack
Deploy Fleet with TLS, wire Zyvor OTA and Device Agent, and record what the evaluation host proved.
-
Runtime adapters
What each workload kind โ systemd, container, k3s, QEMU โ does, and its safety boundary.
-
Troubleshooting
Real operational issues people hit, with the documented fix โ not a generic checklist.
-
FAQ
Licensing, support, and production-readiness questions people ask before adopting Fleet.
Zyvor Fleet manages remote sites as a fleet, not merely clusters. A site
can be a factory gateway, retail server, telecom POP, branch appliance,
rugged Linux box, k3s node, GPU edge server or KVM host. The control plane
declares what should run; a small fleet-agent pulls that desired state,
caches the complete revision locally, and keeps reconciling it when the WAN
disappears โ with no arbitrary remote shell exposed.
For the full picture โ architecture diagram, feature list, quick start, Kubernetes/Helm instructions, security defaults and licensing โ see the README on GitHub.
Three ways to run the control plane¶
-
Bare binary
make build, installfleetdas a systemd service, and point it at a persistent volume. The usual choice for a standalone edge control plane. -
Docker Compose
docker compose up --buildstarts one control plane plus two simulated edge sites โ the fastest way to see the console and protocol end to end. -
Kubernetes / Helm
helm upgrade --install zyvor-fleet ./deploy/helm/zyvor-fleetdeploys one control-plane replica with aReadWriteOncevolume โ intentionally one replica, since the v0.3 embedded store is single-writer.
See the deployment guide for the full production checklist.
- systemd, container (Docker/Podman), k3s, and QEMU/KVM โ deliberately no generic shell workload type. See Runtime adapters. ↩
- "No cloud/control-plane call is necessary to keep the last accepted desired state alive" once a site has cached its revision. See Offline autonomy in the README. ↩
- v0.3 added site maintenance/cordon mode, scoped API tokens, HMAC-signed webhooks, and a bounded mutation audit trail. See Product plan. ↩
- Successful and failed operator/API mutations are recorded without request bodies or credentials, bounded to the most recent 5,000 records. See v0.3 operations. ↩