Deployment overview

Running Zaris comes down to two choices: which deployment model owns the node processes, and which environment you run in. This page explains the models, compares the environments, and links to a step-by-step guide for each.

note

Zaris is free to build with and includes three months of support. Production use is licensed, and the web console locks after the support window ends (the data plane and PowerShell admin keep working). See Support and licensing.

The two deployment models

Every Zaris cluster has a Management Service (the control plane, with the Web Console) and one or more nodes (the data plane that stores your data). The models differ only in who owns the node processes.

The manager resolves its model once at startup from the ZARIS_MGMT_MODE environment variable. The default is supervisor.

Supervisor model

In the supervisor model, the Management Service creates and owns the nodes — it forks, starts, stops, restarts, and scales them. You provision stores with the AdminShell cmdlets or the Web Console, and the manager spawns the node processes locally. This is the model for hosts you manage directly, such as Windows services and VMs. It is also the natural home for the Clustron-signed CA modes 0–2, because nodes enroll for their certificates through the manager.

This is the default; set it explicitly with ZARIS_MGMT_MODE=supervisor.

Attach model

In the attach model, an external orchestrator — Docker, Docker Compose, or Kubernetes — runs the node processes, and the Management Service only observes them while serving the control plane and Console. The manager never forks a node; you register the externally-run store with it (Register-ZrStore, or the registration API). Because one manager observes the whole cluster, the Console and CLI show a single coherent membership view. This is the model for containerized and orchestrated deployments, and the home of CA mode 3 (pre-issued leaves), where the orchestrator mounts each node's certificate.

Select it with ZARIS_MGMT_MODE=attach. In attach mode the manager refuses to create or fork stores — the orchestrator owns node lifecycle.

The two models pair naturally with an environment and a trust mode, but the model is only a setting — you are not locked in.

	Supervisor	Attach
Who runs nodes	Management Service	Your orchestrator
Start / stop / scale via	Zaris cmdlets or Console	Your orchestrator
Certificates	Enrolled (Clustron signs)	Mounted (you issue)
Best for	Windows and VM hosts you manage	Docker, Compose, and Kubernetes

The environments

Choose the environment that matches where you run, then follow its guide. The container-based environments all use the same node image and the attach model.

Environment	Model	You get	When to use it
Windows install	Supervisor	Management Service and Web Console as Windows services, PowerShell modules, and the node runtime — from one package	Hosts and VMs you manage directly; the fastest path to a working cluster with a Console
Docker container	Attach	A plain, non-secured node-only cluster from one image and a shared config	Local development and evaluation; a lightweight, reproducible cluster on a single Docker host
Docker Compose (secured)	Attach	A secured multi-node cluster with a manager, mutual TLS, and token authentication	A secured cluster on one host; testing the mode-3 mounted-certificate workflow before Kubernetes
Kubernetes	Attach	An official Helm chart: a StatefulSet with stable identity, headless discovery, hot kubectl scale-out, readiness-gated rolling updates, a PodDisruptionBudget, out-of-cluster clients, and TLS via Secrets	Orchestrating a self-healing cluster with elastic scale-out and safe rolling updates across a cluster of machines

A note on ports

A running store exposes a small, predictable set of ports, documented on the Admin guide → Ports page:

• Management API and Web Console — the control plane (default 7801 and 7810).
• Node client port — where data-plane clients connect (7861 in the container images).
• Node cluster port — intra-cluster traffic between nodes (7811 in the container images).

Whichever model and environment you choose, clients always connect to the node client ports, and administrators use the Management API and Console.

Next steps

• Run on a Windows host → Windows install.
• Run a plain cluster in containers → Docker container.
• Run a secured cluster with Compose → Docker Compose (secured).
• Orchestrate on Kubernetes → Kubernetes.