Skip to main content
Deployments

Deploy Zaris your way

From an embedded library to a secured, auto-scaling Kubernetes cluster — the same store, the same connection string. Pick the shape that fits where you run today.

One store, many shapes

Start embedded, grow to a cluster

Zaris runs the same code in-process and clustered. Move along this path without rewriting your app — only the connection string changes.

Embedded

In-process

The Zaris engine runs inside your application — no network hop, no servers, no coordinator. Ideal for development, tests, and single-process caches.

  • Fastest path to a working store — one NuGet package
  • Deterministic, dependency-free integration tests
  • Same API you'll use clustered — no rewrite later
services.AddClustronZaris("demo", "zaris://inproc/demo");
YOUR .NET APPLICATION PROCESSYour codeIZarisClientPut / Get / Watch / LockZaris engine (in-proc)partitions live in this processno servers · no coordinatorin-memory
Client app(s)CLUSTER · containers or VMszaris-n0partitions + replicasNodus · security · metricszaris-n1partitions + replicasNodus · security · metricszaris-n2partitions + replicasNodus · security · metricsreplication · RF copies per partitionManager + Consoleobserve · secure · scale
Docker · VMs

Multi-node on Docker or VMs

A real replicated cluster you run with Docker Compose or on plain machines — with a manager and console alongside. Ready-made compose files bring one up in a single command.

  • Replication (RF copies) for availability
  • A secured (token + TLS) demostore out of the box
  • Runs anywhere Docker or .NET runs — including Windows
services.AddClustronZaris("store", "zaris://n0:7861,n1:7861,n2:7861/store");
Recommended at scale

Kubernetes with Helm

A StatefulSet of node pods behind a headless and client Service, plus the manager — installed by the official Helm chart. Kubernetes discovery makes scaling a plain kubectl scale.

  • Hot scale-out — new pods join, the partition map grows, no restart
  • Self-healing convergence after restarts and cold starts
  • Mounted-secret or enrollment TLS, per-pod external access
helm install zaris charts/zaris -n zaris --set node.replicas=5
NAMESPACE: zaris · Helm chartclient Service :7861StatefulSet · zariszaris-0pod · partitionsPVC-free · emptyDirzaris-1pod · partitionsPVC-free · emptyDirzaris-2pod · partitionsPVC-free · emptyDirheadless Service · stable pod DNS + discoveryManagerDeployment + Consolekubectl scale statefulset → map grows onto new pods
OUTSIDE THE CLUSTERExternal clientzariss://zaris-0.ext…/storeTLS · multi-SAN leaf · tokenKUBERNETES CLUSTERper-pod Service / LoadBalancerzaris-0internal + external listeneradvertises its ext addresszaris-1internal + external listeneradvertises its ext addressin-cluster clients use internal DNS (unchanged)
Out-of-cluster

External clients

Let clients outside the cluster connect. Each node advertises an externally-reachable address (the Kafka-style advertised-address model) through a second listener and one Service per pod — in-cluster clients are unaffected.

  • Per-pod NodePort, LoadBalancer, or Ingress addressing
  • TLS with a multi-SAN leaf covering the external hostname
  • A boundary-layer transform — the partition map is untouched
services.AddClustronZaris("store", "zariss://zaris-0.ext.example.com:7863/store?ca=/ca.pem");
Management model

Who runs the nodes?

Two operating models, one console. In supervisor mode the manager runs the nodes; in attach mode your orchestrator runs them and the manager adopts the cluster to observe and secure it.

Supervisor

Manager (supervisor)node 0node 1node 2manager owns node lifecycle

Attach

Orchestrator (k8s / compose)node 0node 1node 2Manager adopts (observes)orchestrator owns lifecycle

The same connection string, everywhere

Whichever shape you choose, clients connect the same way — a single zaris:// /zariss:// string. Change where it points, not your code.