How Clustron Zaris fits your infrastructure
A self-coordinating, replicated in-memory data plane you embed and run yourself — with a built-in console and manager, and no external coordinator to operate. On Kubernetes, Docker, Windows, or any cloud.
One data plane, coordinated by itself
Clients talk to the nodes directly with a single connection string. The nodes form a cluster, replicate partitions, and heal themselves — while the console and manager observe from the side.
Four composable cores, one store
Zaris is what you get when Clustron's building blocks are composed into one distributed store — each solving a hard part of running software across more than one machine.
Clustron Zaris
Partitioned, replicated in-memory key-value store. Owns the data path: puts, gets, transactions, watches, leases, counters and TTL — served straight from the node that owns each partition.
Clustron Nodus
Peer-to-peer membership, leader election and typed messaging. This is why there is no ZooKeeper, etcd or Consul to run — the cluster coordinates itself.
Clustron Security
Mutual TLS with four CA/trust models, offline-verified bearer tokens and deny-by-default RBAC — the same trust fabric across the data plane and the console.
Clustron Observability
Low-allocation rolling metrics on the hot path — rates, gauges and runtime stats — pushed to the manager and exportable over OTLP.
Available by design, not by bolt-on
- No single point of failureEach partition is replicated (RF copies) across nodes. Lose a node and a surviving replica keeps serving; the map only regenerates when every copy of a partition is gone.
- Scales horizontallyAdd pods and the partition map grows onto them — a plain kubectl scale with Kubernetes discovery. The client learns the new topology automatically.
- Self-healing convergenceA live-peer reconciler converges a cold-started or partially-joined cluster to the real membership, and re-replicates under-covered partitions back to full RF.
Self-hosted, on your infrastructure
Clustron Zaris runs entirely inside your environment — your data never leaves it. The same cluster, the same connection string, on whatever you already run.
Kubernetes
Official Helm chart: StatefulSet + headless Service, hot kubectl scale, per-pod external Services, and mounted-secret or enrollment TLS.
Docker & Compose
Ready-made compose files for a multi-node cluster and a secured (token + TLS) demostore — one command to a running cluster.
Windows & cloud VMs
Runs as a plain process from a config file on Windows or any VM. The same connection string reaches it from anywhere.
Trust that spans the whole cluster
- Mutual TLS, four CA modelsAuto/co-located, bring-your-own CA, intermediate CA, or pre-issued leaves. Node↔node is mutual; the client data plane is server-auth with token identity.
- Token authenticationOffline-verified bearer tokens — no round-trip to an auth server on the hot path. Pass them safely via env: or file: references in the connection string.
- Deny-by-default RBACRole-based access control across stores and admin operations, enforced at the node and surfaced in the console.
Every operation, in real time
Throughput, replication, latency, memory and eviction — live in the console and exportable over OTLP to the stack you already run.
Frequently asked
Does Clustron Zaris need an external coordinator?
No. Clustering, leader election and messaging are built in via Nodus. There is no ZooKeeper, etcd or Consul to stand up, secure and operate.
How do clients connect?
With a single connection string — zaris://host1,host2/store (or zariss:// for TLS). The hosts are a seed list with failover; the client then learns the full topology from the cluster. The store name in the path is the cluster id.
How does it scale, and is it lossless?
Scaling out is a hot kubectl scale with Kubernetes discovery — new pods join and the partition map grows onto them with no restart and no data loss. Scale in one step at a time so replication can re-establish RF between steps.
Can clients outside the cluster connect?
Yes. Enable external access and each node advertises an externally-reachable address (Kafka-style advertised addresses) via a second listener, with one Service per pod. Secure it with TLS whose certificate SAN carries the external hostname.
In-process or clustered?
Both, with the same code. Run an embedded in-process store for development and tests, then point the same client at a real multi-node cluster in production.
How is it observed?
Every cluster ships with the web console (real-time throughput, partitions, node health, data and security) and nodes export metrics over OTLP to your existing stack.
Design your cluster with us
From a single embedded store to a secured, multi-node Kubernetes deployment — the docs and the team are here.