Clusters
Connect machines to a team and use them as the storage and execution layer behind VOLT.
TL;DR -- A team cluster is the machine that stores your data and runs the heavy work. VOLT coordinates the workspace, but the cluster daemon and local services are what make uploads, analyses, notebooks, and remote access actually work.
Overview
Clusters are the infrastructure backbone of a team. When you connect one, you are not just registering a hostname. You are enrolling a machine into the workspace so it can run the daemon, maintain local services, store trajectory and analysis data, execute jobs, and expose selected capabilities back to the product.

This is why cluster setup is one of the first things VOLT asks for during onboarding. Without at least one connected cluster, the team has nowhere to process or store its scientific workload.
What lives on a cluster
The default setup brings together four major services:
| Service | Purpose |
|---|---|
| MongoDB | Stores structured metadata, listings, and result projections |
| MinIO | Stores trajectory dumps, GLB models, raster previews, plugins, and other binary artifacts |
| Redis | Handles queue state, caching, and several real-time runtime concerns |
| ClusterDaemon | Maintains the connection to VOLT and orchestrates processing, notebooks, remote access, and job execution |
Those pieces work together locally. The cloud side of VOLT is mostly coordinating and routing, while the cluster side is where the actual workload happens.
Enrollment and lifecycle
Connecting a cluster starts with an enrollment flow. VOLT creates a cluster record, issues an enrollment token, and gives you an install command to run on the target machine.
Once the daemon comes online and begins sending heartbeats, the cluster moves from waiting to connected. Later on, the same lifecycle layer also supports updates, credential reveal, remote-access sessions, and deletion.
One subtle but important detail is that install commands and enrollment tokens are not permanent setup notes. They are part of an active lifecycle flow and can be regenerated when needed.
Reading the cluster listing
The listing tells you both whether a machine is reachable and where it sits in its lifecycle.
| Status | Meaning |
|---|---|
| Connected | The daemon is online and the cluster is actively participating in the workspace |
| Waiting for Connection | The cluster has been created, but the daemon has not connected yet |
| Disconnected | The cluster was known previously, but heartbeats are currently missing |
| Updating | A managed update is in progress |
| Deleting | The cluster is being removed from the team |

Monitoring and health
The monitoring view is where the cluster starts to feel like an operational system rather than a black box. You can see resource usage, connection quality, and service behavior in real time.
That makes it easier to answer questions like:
- is the daemon still connected,
- is the machine short on memory,
- is storage filling up,
- or is the team simply waiting for a worker to become available?
Remote access and data explorers
Clusters also expose a set of controlled diagnostic and remote-access tools through VOLT. Depending on the action, that can include host terminal access as well as explorer-style views into Redis, MongoDB, and MinIO.
These views are meant to help with support, debugging, and verification. They are intentionally narrower than being dropped into each service with full native tooling.
Why clusters matter so much in VOLT
Clusters are the reason the platform can stay team-centric without becoming a centralized data silo. Your trajectories, plugin results, notebook runtimes, and many collaboration artifacts live on infrastructure your team controls.
That design also explains why cluster health affects so many other modules. If the cluster is disconnected, uploads, analyses, notebook sessions, container operations, and several remote features will either pause or fail.
If you want the internal picture of what the daemon is doing once a cluster connects, see Architecture. If you want deployment guidance, continue with Self-Hosting.