What is Ployz? A primitive orchestration core for clusters
Ployz is a primitive orchestration core for clusters in the 1–200 node range. It gives operators a set of single-command operations — add a machine, deploy a workload, branch an environment, promote, roll back, migrate state — each with visible preconditions, a bounded effect, a clear result, and a way to verify what happened. There are no background reconcilers rewriting cluster state, no autoscalers, and no desired-state documents to keep in sync. The cluster does what you tell it, when you tell it, and reports back honestly.
The problem it solves
Section titled “The problem it solves”Most small teams do not run hyperscale infrastructure. They run a handful of machines and need a few strong capabilities: join machines into one private network, deploy and route workloads, move workloads and persistent state, branch and promote environments, roll back cleanly, and diagnose problems when something goes wrong. Modern orchestrators like Kubernetes encode all of that behavior into policy engines — controllers, operators, admission webhooks, autoscalers — that are essential at 10,000 nodes and actively counterproductive at ten.
Ployz is designed around a different bet: small-scale infrastructure gets better when the system exposes real operational primitives instead of hiding them behind reconciler loops. The operator sees the cluster, decides what to do, runs a command, sees the result, and decides the next thing. That is the whole loop.
Go from zero to a running cluster with a deployed workload in minutes.
Install Ployz on Linux or macOS with the one-line installer or from source.
Primitives, not policies
Section titled “Primitives, not policies”Policy belongs at decision time — in the operator’s head, not in cluster manifests. Ployz exposes each infrastructure operation as a single command that completes or fails cleanly and is safe to retry.
| Command | What it does |
|---|---|
ployzctl machine add | Provision a fresh machine into the cluster |
ployzctl machine rm | Drain workloads, transfer state, remove from cluster |
ployzctl migrate apply <workload> --to <machine> | Move a workload, including persistent state, between machines |
ployzctl branch apply <source> <target> | Fork an environment — services, volumes, routing — as a single atomic operation |
ployzctl deploy | Deploy a manifest; promotion is done by deploying into the target namespace |
ployzctl deploy -f rollback.toml | Restore a prior deploy point by re-deploying the previous manifest |
ployzctl image distribute | Clone an image across cluster nodes with ZFS copy-on-write semantics |
ployzctl machine ls | Inspect live machine state and cluster membership |
If you find yourself writing a script to combine multiple ployzctl commands to achieve a workflow, that workflow is a missing primitive.
What Ployz is not
Section titled “What Ployz is not”Ployz does not:
- Run autoscalers, controllers, or reconcilers.
- Maintain a desired-state document that background processes converge toward.
- Silently mutate cluster state between commands.
- Require special nodes or a master to hold cluster authority.
Core components
Section titled “Core components”Ployz is built around three components that work together.
ployzd
Section titled “ployzd”The daemon that runs on each machine. It is disposable: it can crash, upgrade, or restart without disrupting WireGuard tunnels, NATS, the gateway, DNS, or workload containers. On startup it adopts what is already running.
ployzctl
Section titled “ployzctl”The operator CLI. Every operation in the primitive surface is a ployzctl subcommand. The CLI forwards most commands directly to ployzd via a Unix socket.
Data plane
Section titled “Data plane”The set of services that keep serving last good state when ployzd is absent: workload containers, WireGuard mesh, NATS, gateway, DNS, and storage datasets.
How it compares to Kubernetes
Section titled “How it compares to Kubernetes”| Ployz | Kubernetes | |
|---|---|---|
| Target scale | 1–200 nodes | Hundreds to tens of thousands |
| State model | Live state, reported on demand | Desired state, continuously reconciled |
| Operations | Explicit commands | Declarative manifests |
| Background activity | None — no controllers, no reconcilers | Controllers, operators, autoscalers |
| Primitives | Single-command operations | Composable resource types |
| Failure model | Loud failure, safe retry | Eventual convergence |
The operator loop
Section titled “The operator loop”The system is designed around a tight, human-readable loop:
- You observe the cluster with
ployzctl status. - You decide what to do.
- You run one command.
- The command completes or fails cleanly.
- You verify the result.
There is no controller running ahead of you or behind you. There is no manifest to keep in sync. Every state change is an explicit operation triggered by an operator — or by automation acting on their behalf — with a clear return value.
Storage, network, and runtime
Section titled “Storage, network, and runtime”Ployz owns the substrate end-to-end, which is what makes single-command primitives possible.
- ZFS provides instant clone, atomic snapshot, and incremental send — the substrate for branching, migration, and rollback.
- WireGuard provides a flat, controllable overlay network across all cluster nodes.
- Docker (or host processes on Linux) provides container identity and isolation that Ployz controls directly.
- NATS is the control-plane substrate: durable facts, coordination, request/reply commands, and operator-visible state surfaces.
Every node is a peer. There is no master. Coordination and state visibility work on a peer-oriented model so that machine remove is safe regardless of which machine is removed.
Local, self-hosted, and cloud
Section titled “Local, self-hosted, and cloud”A developer running a local Ployz cluster on a Mac gets the same operations as a fleet operator running production workloads on bare metal. Branching, migration, and rollback work the same way. The model does not bifurcate between “dev mode” and “real mode.”