Skip to content

system

Jump to bottom
Thomas Mangin edited this page Aug 16, 2026 · 11 revisions

Pre-Alpha. This page describes behavior that may change.

The system { } block carries the identity of the Ze instance and the global settings that do not belong to a specific subsystem. Hostname and domain for archive filenames and log tags, user management for the SSH server, TLS listeners for the web UI and the Looking Glass, logging targets, and a few smaller knobs. The environment { } block sits alongside it and carries the cross-cutting runtime options.

This page covers the operator-facing pieces. The in-tree configuration guide carries the deeper material on any single block.

System identity

system {
    host   router1;
    domain dc1.example.com;
}

host and domain appear in archive filenames, in the SSH banner, and in log lines. Both support $ENV expansion: a value that starts with $ is looked up as an environment variable.

system {
    host   $HOSTNAME;
    domain $DOMAIN;
}

If the environment variable is empty or unset, the literal string is kept. When host is not configured, it defaults to os.Hostname().

Users and SSH

The user database and the SSH host key live in the Ze blob storage (database.zefs) and are created by ze init. ze init is interactive by default and prompts for a username, a password, an SSH host, and an SSH port. Defaults are 127.0.0.1:2222 and an auto-generated ED25519 host key.

The same database.zefs also holds runtime state that must survive a restart: BFD authentication sequence numbers, DDoS baselines, the NTP last-sync time, traffic-control qdisc snapshots. That store is now opened whenever a config directory is pinned, including when the config itself is read from a file rather than from blob storage. It previously was not, so starting the daemon on a plain config file, or with ZE_STORAGE_BLOB=false, silently lost all of it across restarts. Traffic control does not degrade quietly there: the tc backend refuses to program a qdisc it cannot snapshot, so that path failed startup outright. Which backend holds the config must not decide whether runtime state survives a restart.

When no config directory is pinned, runtime-state persistence stays a best-effort no-op, so a read-only or ephemeral deployment still starts.

Re-initialisation is blocked unless you pass --force. Force moves the old database to database.zefs.replaced-<date> as a backup and creates a new one, and it only works interactively so a piped stdin cannot accidentally wipe your credentials.

The SSH server shares the same user database as the web UI and the REST API. There is one list of users, and every surface reads from it.

Two forms of password are accepted in the config: password "$2a$10$..." (pre-hashed bcrypt) and plaintext-password "secret" (auto-hashed to bcrypt at commit time and removed from the persisted config). The password is never stored in plaintext.

Every credential surface reads the user list of the RUNNING config, not a snapshot taken at boot. A user you delete and reload stops authenticating at once on the web password, on the web session cookie the browser still holds, on the SSH password, on the SSH public key, and on Bearer <user>:<pass> over REST and gRPC. The daemon does not restart, and the 24-hour web session TTL is a ceiling rather than the only test. A connection that is already open outlives the removal until it closes. A session a remote backend granted (RADIUS, TACACS+) is not revoked by the local list, because the local list never authenticated it.

SSH public key authentication

Users can authenticate with SSH public keys instead of (or in addition to) passwords. Supported key types: ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. Multiple keys per user are supported.

Static DNS nameservers

The system { nameserver { } } block configures static DNS nameservers for the Ze daemon's own resolver:

system {
    nameserver {
        primary 8.8.8.8;
        secondary 8.8.4.4;
    }
}

Web UI listener

environment {
    web {
        enabled true;
        server main {
            ip   0.0.0.0;
            port 3443;
        }
    }
}

When no TLS certificate is configured, Ze generates an ECDSA P-256 self-signed certificate on first start with SANs for localhost, 127.0.0.1, ::1, and the listen address.

To serve your own chain instead, name a pki { } store entry with the certificate leaf:

environment {
    web {
        enabled true;
        certificate lan;
        server main {
            ip   0.0.0.0;
            port 3443;
        }
    }
}

The listener sends the leaf certificate and every intermediate certificate the store entry holds, so a client can build the full chain. The reference is fail-closed: a name the store does not hold, or an entry with no private key, stops the web server and rejects the reload. Ze never falls back to a self-signed certificate for a configured name.

error: environment.web.certificate: pki: certificate no-such-cert not found (available: lan)

A reload that changes the certificate rotates the served material through a per-handshake lookup, so the listener does not rebind and open connections survive. Bad material is refused and the previous certificate stays in place. ze.web.certificate sets the same name from the environment and takes precedence over the config file. The name accepts 1 to 255 characters from [A-Za-z0-9._-].

The certificate leaf applies whenever the environment { web { } } block exists, whatever started the server. It is not gated on enabled true, so --web, ze.web.listen, and ze.web.enabled all serve the chain the block names.

The --insecure-web command-line flag turns off authentication and forces the listener back to 127.0.0.1. It exists for development. Do not use it on a public interface. The insecure leaf in the config block is the one setting a dormant block does NOT supply, because it removes authentication: the block decides web authentication only when the block also starts the server and names the listen address. In every other case the daemon keeps authentication on and logs a WARN naming environment.web.insecure. Set ze.web.insecure=1 to remove web authentication from the environment.

Looking Glass listener

environment {
    looking-glass {
        enabled true;
        server main {
            ip   0.0.0.0;
            port 3443;
        }
    }
}

The Looking Glass runs on its own port, separate from the web UI. It is read-only and unauthenticated by design.

TLS is on by default. A looking-glass block with no tls leaf serves https://. Write tls false in the block, or set ze.looking-glass.tls=false, to serve plaintext behind a TLS-terminating proxy. A box with no blob storage that only inherited the default gets a warning naming ze init rather than a failure, so a hardening default does not remove a working looking glass. An explicit tls true on such a box is an error.

An optional bearer token gates the routes. Write it in the token leaf, or set ze.looking-glass.token.

The tls, token, and server settings apply whenever the block exists, whatever started the server. ze.looking-glass.enabled and ze.looking-glass.listen start a listener without any enabled true leaf, and the block still supplies its settings to it. When no block names a server at all, an env-started looking glass binds 0.0.0.0:8443.

See looking-glass for the deeper reference.

MCP listener

environment {
    mcp {
        enabled true;
        server main {
            ip   127.0.0.1;
            port 8080;
        }
    }
}

The MCP server defaults to 127.0.0.1:8080. That is deliberate: MCP is local-only unless you explicitly override it. Bearer-token authentication is available through ze.mcp.token or the token leaf. A token written beside an explicit auth-mode none does not authenticate: the server builds its accept-all authenticator, and the guard below reads the mode the server will actually use.

Every server entry under environment { mcp { } } must name its port explicitly. One entry with an ip and no port makes MCP start no listener at all, and both ze config validate and ze doctor name the entries that are missing one. The YANG refine port { default 8080; } in ze-mcp-conf.yang does NOT reach the daemon, unlike the same refine on environment.web and environment.gnmi, so following it is exactly the mistake the message reports. Before this check existed such an entry reached the binder as 127.0.0.1: and bound a kernel-chosen port that nothing could probe.

Management listener guard

Ze refuses to start an unauthenticated management service on a non-loopback listener. The guard runs once at boot, after every address and credential is resolved and before anything binds, so a refusal leaves the daemon fully stopped rather than half-started. It exits with status 1 and prints one line per offending listener.

error: refusing to start gNMI on non-loopback listener "0.0.0.0:9339" without authentication
  set ze.gnmi.token (or environment.gnmi token), or bind to 127.0.0.1/::1 only
Service Authentication that permits a remote listener
Web in insecure mode Drop insecure and configure users
MCP ze.mcp.token, or an environment.mcp auth-mode that gates every request (bearer, bearer-list, oauth)
gNMI ze.gnmi.token or environment.gnmi token
REST and gRPC API ze.api-server.token, or initialize zefs users

Literal addresses in 127.0.0.0/8 and ::1 count as loopback. Wildcard addresses (0.0.0.0, ::, :port), empty addresses, DNS names, and the name localhost all count as non-loopback, because the guard fails closed when it cannot prove an address is local. A surface whose feature gate is compiled out of the binary never declares, because it cannot bind.

The public Looking Glass is a separate, intentionally unauthenticated read-only service and is not covered by this guard.

ze doctor --json and ze config validate report the same exposure offline: config-gnmi-invalid for a remote gNMI listener with no token, config-mcp-invalid for an MCP block that asks for a remote bind with no authentication. Neither command can read another process's environment, so a listener published only by an environment variable is caught at boot instead.

A dormant block still names the listener it authenticates

enabled answers "start a listener". It never answers "how does this service authenticate". A block without enabled true still supplies the token, the TLS material, and the address of a service that ze.web.enabled, ze.gnmi.enabled, ze.looking-glass.enabled, ze.api-server.rest.enabled, or ze.api-server.grpc.enabled starts.

Two upgrade consequences follow. A service you reached from off-box through the 0.0.0.0 default now answers only where its block says, so delete the server entry or name the address you want in order to publish on every interface again. And a boot that used to be refused for a missing credential now finds the credential the operator had already written in the dormant block.

Logging

environment {
    log {
        level        warn;
        backend      stderr;
        bgp.reactor  debug;
        bgp.routes   info;
        plugin.relay warn;
    }
}

level is the base level for every subsystem. The per-subsystem leaves override it. Backends are stderr (default), stdout, or syslog (with a destination). Full coverage in logging.

DNS resolver

Ze has a built-in cached DNS resolver. Every component uses it, so there is one cache and one set of settings instead of one per subsystem.

environment {
    dns {
        server     8.8.8.8:53;
        timeout    5;
        cache-size 10000;
        cache-ttl  86400;
    }
}
Field Default Description
server "" Upstream DNS server. Empty uses /etc/resolv.conf.
timeout 5 Query timeout in seconds (1 to 60).
cache-size 10000 Maximum cache entries. 0 disables caching.
cache-ttl 86400 Maximum cache TTL in seconds. 0 uses only the response TTL.

The cache respects DNS response TTLs: entries expire at min(response TTL, cache-ttl). Records with TTL 0 are never cached (RFC 1035).

TCP and reactor settings

environment {
    tcp {
        attempts 3;
    }

    reactor {
        update-groups true;
    }
}

tcp/attempts controls the connection retry count. reactor/update-groups toggles the cross-peer UPDATE grouping optimisation: when enabled (the default), peers that share the same encoding context share a single UPDATE build, and the wire bytes are fanned out to every group member. Disable it for ExaBGP-compatibility or when debugging per-peer encoding issues.

PeeringDB integration

system {
    peeringdb {
        url    "https://www.peeringdb.com";
        margin 10;
    }
}

Used by ze resolve peeringdb max-prefix <ASN>, which queries PeeringDB for each peer's ASN and updates the prefix maximums automatically with the configured margin. The URL is configurable for private mirrors.

SSH server

The SSH server is configured under environment { ssh { } }. It is disabled by default and must be explicitly enabled. The host key and user database are created by ze init.

environment {
    ssh {
        enabled true;
        host-key /etc/ze/ssh_host_ed25519_key;
        idle-timeout 600;
        max-sessions 16;
        server main {
            ip   0.0.0.0;
            port 2222;
        }
    }
}
Leaf Type Default Description
enabled boolean false Enable the SSH server.
host-key string config dir + ssh_host_ed25519_key Path to the host key file. Auto-generated if missing.
idle-timeout uint32 600 Idle timeout in seconds before a session is closed.
max-sessions uint16 — Maximum concurrent SSH sessions.

The server list works the same as the web and looking-glass listeners: each entry has a name, an ip (default 0.0.0.0), and a port (default 2222). You can define more than one listener if you need to bind to multiple addresses.

Plugin configuration

Plugins are declared under plugin { }. Use internal with use for built-in plugins and external with run for external process plugins.

plugin {
    # Built-in plugin (in-process, lowest latency)
    internal rib {
        use bgp-rib
    }

    # External plugin (separate process, any language)
    external my-filter {
        run      "/usr/local/bin/my-filter --json";
        encoder  json;
        respawn  true;
        timeout  10s;
    }
}
Leaf Type Description
name string (1..64) Plugin name (the list key).
use string Built-in plugin name. Mutually exclusive with run.
run string Command line to execute (external process). Mutually exclusive with use.
encoder enum: json, text Event encoding format.
respawn boolean Respawn the process if it exits (external only).
timeout string Startup timeout (e.g. 10s, 1m).

The list key is a label you choose, and use names the registered plugin. Dependency resolution keys on the registered name, not on the label, so internal rs { use bgp-rs } pulls in the plugins bgp-rs declares. A label that differs from the plugin name is fully supported.

A config whose only top-level blocks are plugin { } and interfaces boots the same daemon as any other config. There is one runtime and one parser, so ze config validate and ze start cannot reach different verdicts on the same bytes. ze start --plugin <name> works for every config, and ze start --web is no longer refused for a config with no bgp { } block.

A top-level env { } block is refused. It was never read by the daemon, and both of the keys it carried have homes under environment { }.

See External plugins for the full development guide covering the stdin/stdout protocol, event types, and worked examples.

Environment tuning

The environment { } block contains several sub-containers that control process management, plugin API behaviour, debug toggles, and protocol-level knobs. All leaves have sensible defaults; you only need to set them when tuning or troubleshooting.

daemon

Process management. Controls privilege dropping and daemonisation.

environment {
    daemon {
        pid       /run/ze.pid;
        user      zeuser;
        daemonize true;
        drop      true;
        umask     0137;
    }
}
Leaf Type Default Description
pid string — PID file path.
user string zeuser System user for privilege drop.
daemonize boolean — Run as a background daemon.
drop boolean true Drop privileges after startup.
umask string 0137 File creation mask (octal).

api

Plugin API tuning. Affects how Ze communicates with external processes.

Leaf Type Default Description
ack boolean true Acknowledge API commands.
chunk int32 1 Maximum lines before yield.
encoder enum: json, text json Default encoder for the plugin API.
compact boolean — Compact JSON encoding for INET.
respawn boolean true Respawn dead plugin processes.
terminate boolean — Terminate Ze if a plugin process dies.
cli boolean true Create the CLI named pipe.

debug

Debug toggles. All are off by default unless noted.

Leaf Type Description
pdb boolean Enable Python debugger (legacy).
memory boolean Track memory usage.
configuration boolean Debug configuration parsing.
selfcheck boolean Run internal consistency checks.
route string Debug a specific route prefix.
defensive boolean Enable defensive checks.
rotate boolean Rotate debug output files.
timing boolean Log operation timing.
pprof string pprof HTTP server address (e.g. :6060).

chaos

Fault injection for testing. Disabled unless seed is set to a non-zero value.

Leaf Type Default Description
seed int64 — PRNG seed. 0 disables fault injection.
rate string 0.1 Fault probability per operation (0.0-1.0).

cache

Attribute deduplication cache. Reduces memory when many peers share identical path attributes.

Leaf Type Default Description
attributes boolean true Cache path attributes for deduplication.

bgp

Protocol-level BGP environment knob.

Leaf Type Default Description
openwait int32 120 Seconds to wait for OPEN after TCP connect.

Serial console

For headless CPE devices, Ze can configure serial console ports. Works on both gokrazy (no systemd) and standard Linux via termios. On systemd hosts, detects active serial-getty and skips the device with a warning.

system {
    console {
        device ttyS0 {
            speed 115200;
        }
    }
}
Field Type Default Description
device/<name> list key -- Serial device name (bare name, e.g. ttyS0, ttyUSB0).
device/<name>/speed enum 115200 Baud rate: 9600, 19200, 38400, 57600, 115200.

Connection tracking

Declarative connection tracking management under system { conntrack { } }. Controls helper module loading, table sizing, per-protocol timeouts, and TCP behavior flags.

system {
    conntrack {
        module [ ftp sip ];
        table-size 262144;
        hash-size  65536;
        accounting;
        tcp {
            timeout-established 7200;
            be-liberal;
        }
    }
}

Helper modules

Loaded via modprobe on boot. Load-only: removing a module from config stops loading on next boot but does not unload at runtime.

Module Kernel module
ftp nf_conntrack_ftp
h323 nf_conntrack_h323
sip nf_conntrack_sip
pptp nf_conntrack_pptp
tftp nf_conntrack_tftp
sane nf_conntrack_sane
irc nf_conntrack_irc
amanda nf_conntrack_amanda
netbios-ns nf_conntrack_netbios_ns
snmp nf_conntrack_snmp
nfs nf_conntrack_nfs
sqlnet nf_conntrack_sqlnet

Table sizing

Field Type Range Description
table-size uint32 1..2097152 Maximum conntrack table entries (nf_conntrack_max).
hash-size uint32 1..2097152 Hash table buckets (nf_conntrack_buckets).
expect-max uint16 1..65535 Maximum expected connections (nf_conntrack_expect_max).

Global flags

Field Effect
accounting Enable per-connection byte/packet counters.
timestamp Enable per-connection timestamps.

Sysctl values are routed through the sysctl plugin via EventBus. Keys managed by conntrack are rejected if also set in sysctl { } (dual-setting prevention).

CLI

show system conntrack       # Live state from /proc/sys

Storage SMART management

YANG-modeled disk health monitoring under storage { }. SMART auto-enables on detected ATA and NVMe devices and polls health periodically. Temperature alerting is three-tier: an informational warning, a rate-of-change warning, and a critical error, all raised on the report bus. Scheduled self-tests run short daily and extended weekly (with a day-of-week constraint), and an in-progress test is detected so duplicate tests are skipped. It is pure ioctl, with no smartctl binary, so it is gokrazy-safe. ze doctor verifies SMART accessibility when enabled.

show storage smart

Per-device output covers health, temperature, power-on hours, error count, NVMe percent-used and available-spare, and the self-test schedule.

PKI certificate store

The pki { } block holds CA certificates and device certificates with private keys, shared by the IPsec and TLS consumers. Certificates are parsed from base64-DER, private keys are detected as PKCS8/SEC1/PKCS1, and key material uses $9$ sensitive encoding. The store validates chains, checks expiry (health degraded at 30 days, down when expired), and raises report-bus warnings as expiry approaches.

show pki certificates
show pki certificate <name>
show pki certificate <name> pem
show pki certificate <name> bundle pem
show pki certificate <name> fingerprint

The pem and bundle pem sub-commands export PEM for downstream consumers; fingerprint shows the certificate fingerprint.

A TLS listener names a store entry rather than a file path, and ServerTLSMaterial gives it the leaf certificate plus every stored intermediate. Three listeners read the store today:

Listener Leaf
Web UI and REST/gRPC HTTPS environment { web { certificate <name>; } }
as112 DoT and DoH tls { certificate <name>; } inside the as112 block
geodns DoT and DoH tls { certificate <name>; } inside the geodns block

On as112 and geodns the certificate leaf and the cert-file / key-file pair are mutually exclusive; setting both is a configuration error. The PKI store lives in the hub process, so a geodns or as112 plugin started as an external process cannot resolve a store name: its secure listeners then do not start and the error is logged. Cleartext DNS is unaffected.

ze doctor carries the web-tls-certificate check for the web listener, reporting doctor-tls-reference for a name the store cannot resolve and doctor-tls-expired for material past its validity.

Self-update

Ze can periodically check for updates, and optionally download, verify, and install them automatically. The full feature covers fleet-scale rollout with spread scheduling, maintenance windows, and server-side pause.

Check-only (default)

system {
    update-check {
        url      "https://updates.example.com/ze/version.json";
        interval 86400;
    }
}
Field Type Default Description
url string -- HTTPS URL serving the version manifest.
interval uint32 86400 Check interval in seconds (range 60..604800, default daily).

Automated updates

system {
    update-check {
        url https://update.example.com/version.json;
        interval 3600;
        auto-apply true;
        spread 1800;
        maintenance-window {
            start 02:00;
            end 06:00;
        }
        restart {
            time 03:00;
        }
    }
}
Field Type Default Description
auto-apply boolean false Enable automated download, verify, and stage.
spread uint32 3600 Maximum random delay before download (deterministic per device+version).
maintenance-window/start string -- Start of binary replacement window (HH:MM).
maintenance-window/end string -- End of binary replacement window (HH:MM).
restart/time string -- Restart time (HH:MM). Use restart { immediate; } for immediate restart.

SHA-256 verified download, atomic binary replacement via rename with .prev rollback. Manual CLI commands: update system firmware {check,download,apply,restart,rollback}. See Self-Update for the full guide.

ze update-serve

Standalone update server for build infrastructure:

ze update-serve --listen :8080

Serves an enhanced manifest at /version.json, binaries at /<goos>/<goarch>, and SHA-256 digests. Supports file-based and SIGUSR1 pause toggling.

System readiness: ze doctor

Offline pre-start checks to verify the environment is ready.

ze doctor
ze doctor --json config.conf
ze explain <code>

ze doctor detects the runtime platform (gokrazy, systemd, container, plain-linux, darwin) and probes its capabilities, then runs platform-aware coherence checks (gokrazy /perm writability, container read-only root, machine-id presence). It is config-driven: it verifies the runtime dependencies the config declares, including BGP MD5 support, the VPP API socket, the IPsec path, NTP/RPKI/BMP reachability, writable destinations, and random-seed persistence.

Checks: config syntax, YANG validation, TLS certs, VPP socket and version, kernel modules, interfaces, SSH host key, listener conflicts, plugins, storage integrity, dangling config references, disk space, DNS resolver, clock skew. --json emits stable diagnostic codes; ze explain <code> gives remediation guidance. Exit code 0 means ready. See Health Checks for the full check list.

Config nobody receives. doctor-config-root-unclaimed reports a configured subtree that Ze stores and delivers to no plugin and no hub handler, so it has no effect. It fires when the owning plugin is not built into this binary, when it did not load, or when its config root is missing. The check fails closed: when no plugin in the build declares a config root at all, it reports doctor-config-claims-unavailable rather than flagging every root in the tree.

The listener inventory probes the transport the daemon binds. A DNS service (as112, geodns) binds UDP and TCP on every endpoint, so both are probed. Previously only TCP was probed and the check passed while UDP was held by something else. A service whose YANG carries no listen default now registers its default from its own package, so ze doctor probes the address the daemon binds rather than nothing at all.

Tech-support bundle: ze support

ze support generates an offline tech-support archive with 20 pure-Go collection modules (no shell-outs, gokrazy-safe), one JSON file per module.

ze support
ze support --module config,routes
ze support --exclude crashes
ze support --since 1h
ze support --sensitive --reason "ticket-1234"
ze support --json

Privacy-by-default keeps secrets out unless --sensitive is given. The archive is named ze-support-<hostname>-<timestamp>.tar.gz. See Health Checks for the module list.

Runtime health

show health

The health registry aggregates status from running components (bgp, fib, firewall, iface, plugins, vpp, ipsec, pki, l2tp). Reports healthy, degraded, or down. The /health HTTP endpoint returns HTTP 503 when any component is down. See Health Checks.

Crash capture

Automatic stderr redirect captures panic stack traces from any goroutine. Forwarded to syslog and persisted to crash files on disk. Crash reports are enriched with build and runtime metadata (version, build date, uptime) and ring buffer context (last 64 log entries before the panic). Panics caught by the bubbletea TUI produce a full crash report rather than a bare stack trace.

show crashes
show crashes latest

Crash directory: /perm/ze/crash/ on gokrazy, fallback chain for other platforms. Configurable via ze.crash.dir and ze.crash.keep environment variables.

Debug flags

Persistent per-subsystem debug flags are stored in ZeFS and survive daemon restarts. They are applied after the config-driven log levels during startup. Resolution is three-tier: a global override wins, then a per-subsystem key, then the default (off). Hierarchical prefixes work, so enabling bgp covers all bgp.* subsystems.

ze debug enable bgp
ze debug enable all
ze debug disable bgp.reactor
ze debug show

Config schema stamp

Config files carry a schema version stamp. On load, Ze checks the stamp against its current schema version. When loading a config from a newer version, downgrade recovery kicks in: incompatible fields are pruned and a warning is logged.

Graceful listener migration

When a config reload changes listener endpoints (web UI, Looking Glass, REST, gRPC, MCP), Ze migrates gracefully: the new listener starts before the old one stops. In-flight connections on the old listener are drained before close.

A reload rebuilds the credentials of the running REST and gRPC servers. Add a token, rotate it, remove it, or edit the user list, and the change takes effect on the next reload with no restart and no rebind.

The web and MCP servers choose their authentication once, when they are built. A reload that asks either of them for a different mode fails the whole commit before anything is applied:

<service> cannot change its authentication while running: it is serving
<mode> and the config asks for <mode>; restart ze to apply it

The management listener guard runs again over the pair each service holds once the reload applies, and it reads the rebuilt authentication rather than the mode the server started with. A reload that removes the API credentials and moves the same listener off loopback is refused for that reason, and the refusal restores the credentials the reload had already installed.

See also

Adapted from main/docs/guide/configuration.md.

Unreviewed draft. This wiki was authored in bulk and has not been reviewed. File corrections on the issue tracker.

AGPL-3.0 | Source on GitHub | Discord | Edit this page

Home

About

First Steps

Configuration

Operation

Interfaces

Plugins

Plugin Development

Chaos Testing

Blueprints

Development

Reference

Clone this wiki locally