Volt Docs

Architecture Overview

Volt is built on Linux-native primitives rather than custom daemons. Containers use systemd-nspawn, VMs use KVM, storage uses content-addressed hashing, and everything is managed through systemd. No Docker daemon. No containerd. No shims.

Platform Components

┌──────────────────────────────────────────────────────────────────┐
│                         volt CLI                               │
│                    (single Go binary)                            │
└──────────────┬──────────────┬──────────────┬────────────────────┘
               │              │              │
     ┌─────────▼──────┐ ┌────▼────────┐ ┌───▼──────────┐
     │   Voltainer    │ │  Voltvisor  │ │  Stellarium  │
     │  (containers)  │ │   (VMs)     │ │    (CAS)     │
     ├────────────────┤ ├─────────────┤ ├──────────────┤
     │ systemd-nspawn │ │ KVM/QEMU    │ │ SHA256 store │
     │ machinectl     │ │ Stardust    │ │ dedup blobs  │
     │ nsenter        │ │ cloud-init  │ │ refs/manifst │
     └───────┬────────┘ └──────┬──────┘ └──────┬───────┘
             │                 │               │
     ┌───────▼─────────────────▼───────────────▼───────┐
     │                    systemd                       │
     │  units · targets · journald · cgroups · timers  │
     └───────────────────────┬─────────────────────────┘
                             │
     ┌───────────────────────▼─────────────────────────┐
     │                  Linux Kernel                    │
     │   namespaces · cgroups v2 · KVM · nftables      │
     │   Landlock · seccomp · capabilities             │
     └─────────────────────────────────────────────────┘

The volt CLI is a single statically-compiled Go binary that orchestrates three subsystems: Voltainer for containers, Voltvisor for virtual machines, and Stellarium for content-addressed storage. All three are unified under the Workload abstraction.

Voltainer — Container Runtime

Voltainer runs containers using systemd-nspawn, the container runtime built into systemd. No daemon process — containers are first-class systemd services.

How It Works

  1. Image → Rootfs: volt image pull uses debootstrap to create clean root filesystems, or volt image import to import existing tarballs.
  2. Create: volt container create copies the image rootfs into /var/lib/volt/containers/<name>/ and generates a .nspawn config + systemd unit file.
  3. Start: volt container start activates the systemd unit, which launches systemd-nspawn with the configured isolation.
  4. Exec: volt container exec uses nsenter to enter the running container's namespaces.
  5. Logs: All output goes to journald — unified with system logs, queryable with journalctl.

Backend Architecture

Volt uses a pluggable backend interface (ContainerBackend) with two implementations:

BackendUse CaseDependencies
systemd Production — full isolation systemd-nspawn, machinectl, nsenter
proot Rootless / testing proot (no root required)

Backends register via init() functions, making the system extensible.

Container Lifecycle

  image pull        container create        container start
       │                    │                       │
       ▼                    ▼                       ▼
  ┌──────────┐     ┌────────────────┐      ┌────────────────┐
  │ Download │     │ Copy rootfs    │      │ systemctl      │
  │ rootfs   │────▶│ Generate unit  │─────▶│ start unit     │
  │ (deboot) │     │ Write .nspawn  │      │ (nspawn runs)  │
  └──────────┘     └────────────────┘      └───────┬────────┘
                                                   │
                            ┌──────────────────────┤
                            │                      │
                            ▼                      ▼
                   container exec         container stop
                   │                       │
                   ▼                       ▼
              ┌──────────┐          ┌────────────┐
              │ nsenter  │          │ systemctl  │
              │ into ns  │          │ stop unit  │
              └──────────┘          └────────────┘

Voltvisor — Virtual Machine Management

Voltvisor manages KVM-based virtual machines through the same volt CLI. VMs get the same lifecycle commands as containers but with hardware-level isolation.

Capabilities

VM File Structure

/var/lib/volt/vms/ ├── my-vm/ │ ├── config.yaml ← VM configuration (CPU, RAM, disk) │ ├── disk.qcow2 ← Virtual disk image │ └── cloud-init.yaml ← Cloud-init user data

Stellarium — Content-Addressed Storage

Stellarium is Volt's content-addressed storage (CAS) system. Every blob is stored by its SHA256 hash, providing automatic deduplication and integrity verification.

How CAS Works

# Build a directory into CAS
sudo volt cas build /path/to/app

# Check CAS status
sudo volt cas status

# Verify integrity of all objects
sudo volt cas verify

# Garbage collect unreferenced objects
sudo volt cas gc --dry-run
sudo volt cas gc

Storage Layout

/var/lib/volt/cas/ ├── objects/ │ ├── ab/ │ │ └── abcd1234...sha256 ← Content blob (immutable) │ └── ef/ │ └── efgh5678...sha256 └── refs/ ├── myapp-v1.json ← Manifest (file map + metadata) └── myapp-v2.json

The two-level directory structure prevents filesystem limitations (ext4's ~64K files per directory limit) while keeping lookups fast.

Deduplication

If three containers share the same nginx binary, CAS stores it once. Each container's filesystem uses hard-links pointing to the same blob. Zero wasted space.

Bundles

Volt can package CAS objects into portable .vbundle files — ZIP archives containing manifests and blobs with SHA256 verification:

sudo volt bundle create myapp-v1.vbundle --ref myapp-v1
sudo volt bundle inspect myapp-v1.vbundle
sudo volt bundle import myapp-v1.vbundle
sudo volt bundle verify myapp-v1.vbundle

Unified Workload Abstraction

The Workload layer abstracts across containers, VMs, and services. A single command can list, start, stop, or inspect any workload type:

# List all workloads (containers + VMs + services)
sudo volt ps

# Inspect any workload
sudo volt ps inspect myapp

# Freeze/thaw (containers: cgroup freezer; VMs: SIGSTOP/SIGCONT)
sudo volt workload freeze myapp
sudo volt workload thaw myapp
Workload TypeBackendIsolation
Voltainer (container) systemd-nspawn Namespaces, cgroups, capabilities
Voltvisor (VM) KVM / QEMU Hardware virtualization
Service systemd unit Service sandboxing

Constellations — Multi-Service Stacks

Constellations are Volt's compose system. Define multi-container stacks in a volt-compose.yaml file and manage them as a unit:

version: "1"
services:
  web:
    image: debian-minimal
    command: nginx -g "daemon off;"
    ports:
      - "80:80"
    volumes:
      - webdata:/var/www
    depends_on:
      - db
  db:
    image: debian-minimal
    command: postgres
    volumes:
      - pgdata:/var/lib/postgresql

volumes:
  webdata:
  pgdata:
# Deploy the stack
sudo volt compose up

# Check services
sudo volt compose ps

# View logs
sudo volt compose logs

# Tear down
sudo volt compose down

Under the hood, Constellations create a systemd target with individual service units, bridge networks, and volumes.

File Layout

/etc/volt/ ← Configuration ├── config.yaml ← Main platform config ├── trust-policy.yaml ← Trusted signers (OIDC, KMS, local) ├── firewall-rules.json ← nftables rule metadata ├── network-policies.json ← Workload-to-workload network policies ├── license/ ← License key + X25519 keypair ├── profiles/ ← Security profiles │ ├── webserver.landlock ← Landlock filesystem rules │ ├── database.landlock │ ├── default-plus-networking.json ← Seccomp filters │ └── strict.json └── sysctl/ └── 90-armored-hardening.conf ← Kernel hardening params /var/lib/volt/ ← Runtime data ├── containers/ ← Container rootfs directories │ └── web/ ← rootfs for container "web" ├── images/ ← Base images (debootstrap) │ └── debian-minimal/ ├── vms/ ← VM configs and disk images ├── volumes/ ← Named volumes (dir or ext4) ├── cas/ ← Stellarium content-addressed store │ ├── objects/ ← SHA256-addressed blobs │ └── refs/ ← Manifests / references ├── state/ ← State metadata ├── backups/ ← System backup archives └── workload-state.json ← Workload abstraction state /var/lib/machines/ ← systemd-nspawn default (machinectl)

State Management

Volt stores state in simple files — no database required:

StateFormatLocation
Workload stateJSON/var/lib/volt/workload-state.json
Volume metadataJSONPer-volume in /var/lib/volt/volumes/
Firewall rulesJSON/etc/volt/firewall-rules.json
Network policiesJSON/etc/volt/network-policies.json
LicenseYAML/etc/volt/license/license.yaml
Platform configYAML/etc/volt/config.yaml

All JSON writes use atomic operations (write to temp file, then rename) to prevent corruption.