Deployment models
You run a Clustron Zaris cluster in one of two models: supervisor or attach. They differ in a single question — who owns the node processes? — and that difference changes how you start nodes, how you scale, and how you turn on security.
A manager resolves its model once at startup from the ZARIS_MGMT_MODE environment variable, which defaults to supervisor. Clients and tools do not guess the model; they read it from the manager's /health endpoint, which reports the mode and the capabilities that follow from it (supervisesNodes, createsStores). The console and CLI display the mode, so you always know which one you are looking at.
The table below compares the two models. The sections that follow explain each in detail.
| Supervisor | Attach | |
|---|---|---|
| Who starts the nodes? | The manager forks and owns them | An orchestrator (Docker, Kubernetes) |
| Manager's role | Owner — starts, stops, and reconfigures nodes | Observer — watches and adopts nodes |
| Create a store from the manager? | Yes (New-ZrStore) | No — adopt an orchestrator-defined store with Register-ZrStore |
| Scale the cluster | Add or remove a Server with the manager | Change the orchestrator's replica count |
| Push config to nodes at runtime? | Yes | No — config is declared up front |
| Typical environment | Bare metal, VMs, Windows service | Containers, Kubernetes |
| View from one manager | Per-machine slice, aggregated across managers | Whole cluster |
Supervisor mode
In supervisor mode the manager is a true process supervisor: it launches the node processes itself, on its own machine, and owns their lifecycle.
Because the manager owns the processes, it can start and stop nodes on demand, push new configuration, and provision security material for the nodes it runs.
This is the most hands-on model and the natural fit for bare-metal, VM, or Windows service deployments, where Clustron Zaris manages everything itself. Each machine runs its own manager on port 7801, and a manager supervises the nodes on its machine. A multi-machine cluster is a workspace of those managers; New-ZrStore creates the store's share on every connected machine, and the console and CLI aggregate the per-manager views into one picture of the whole cluster. Scaling is done in units of a Server (a machine) with Add-ZrServer and Remove-ZrServer. See Elastic scaling.
Attach mode
In attach mode something else — usually Docker Compose or Kubernetes — starts the node processes. The manager forks nothing. It attaches to the running nodes, adopts them into a store, and then observes them.
This is the model for containers and Kubernetes, where the platform — not Clustron — runs, restarts, and schedules processes. You define the store with the orchestrator and adopt it with Register-ZrStore; New-ZrStore is refused against an attach-mode manager and points you at the adoption path. One manager attached to the cluster observes every node, which gives you a single coherent view of membership and topology. Scaling is the orchestrator's job — change the replica count and the manager reconciles ownership as nodes appear and disappear.
Because the manager is only an observer here, it cannot reconfigure a running node — and that has a direct consequence for security.
In attach mode the manager cannot reach into a running node and reconfigure it. You cannot "turn on TLS" from the console and have it take effect on nodes the orchestrator owns. Instead, bake security and TLS into the node configuration that the orchestrator mounts, so nodes come up already secured. See Security and TLS for the declarative pattern.
Which model to use
Choose the model that matches who runs your processes.
- Running on VMs, bare metal, or as a Windows service? Use supervisor, and let the manager own the nodes and operate them for you.
- Running in Docker or Kubernetes? Use attach, let the platform run the processes, and let one manager observe the whole cluster. This is the recommended model for containerized deployments.