JailOps
Get started

FreeBSD native · Open source · API-first

DevOps. SecOps. JailOps.

FreeBSD infrastructure, beautifully managed.

A modern platform for FreeBSD jails. Provision, orchestrate, replicate and back up your workloads, from one host to an entire fleet.

Get started Features Source code

One platform, from a single host to a fleet

Jails only, ZFS only. Every host has its own API and console, so a single machine is complete on its own. Hubs and fleets are additive.

  • Projects and trust

    Projects are namespaces that are granted networks and storage, with quotas. Certificates, tokens and users carry a role and a project scope, and an empty project list never means everything.

    Projects and trust

  • ZFS clones, generations, storage

    Thin jails are ZFS clones of immutable image generations. Upgrades swap the root and keep your data, and rollback scopes keep root and data decisions apart.

    ZFS and images

  • VNET and PF networking

    Managed bridges with explicit address ranges and one PF anchor per jail. No DHCP, no router advertisements, no SLAAC: addresses are allocated and written down.

    Networking

  • Encrypted, deduplicated backups

    The host chunks, compresses and encrypts. The repository server, on a directory or S3, holds no key and can never read what it stores. This is not ZFS send.

    Backups

  • Declarative fleets

    jailops-sync plans and applies a git repository of YAML across hosts, touches only what it owns, and never deletes anything it did not create.

    Fleet management

  • API, SDK and consoles

    One REST API drives the CLI, the Go SDK, jailops-sync and the web consoles for the host and for the backup node. Nothing is second-class.

    API and consoles

See it work

A terminal session and the two web consoles. The terminal output is an example that follows the shape of the real CLI output, using documentation addresses. The console screenshots are taken from the consoles running in demo mode on built-in demo data.

jailops, example session
$ jailops network create dmz --subnet 192.0.2.0/24 \
    --gateway 192.0.2.1 --range 192.0.2.10-192.0.2.40
network/dmz created

$ jailops jail create web --image freebsd-15@stable \
    --network dmz --memory 2G --autostart
jail/web created

$ jailops jail start web
jail/web started

$ jailops jail list
NAME   STATE     IMAGE               GEN   ADDRESSES    AGE
web    running   freebsd-15@stable   g1    192.0.2.10   8s

$ jailops jail snapshot create web before-upgrade
snapshot/before-upgrade created

$ jailops jail upgrade web --dry-run
dry-run: would upgrade jail web from g1 to g2
The JailOps host console in dark theme, listing seven jails with their state, image, addresses and drift. A banner reads: Demo mode, canned data.
Host console, jail list. Demo data.
The JailOps backup node console overview in dark theme, stating that the node holds no encryption key, with repository statistics. Demo data.
Backup node console, overview. Demo data.

Two consoles, two roles

The host console is embedded in jailopsd. The backup node console is embedded in jailops-backupd, which has no jail, ZFS or key code at all. Each console is its own small app and may only call the API prefixes registered for it.

Open either console in demo mode with ?demo appended to its URL: it runs on canned data and sends nothing to a server.

How it fits together

Hosts are independent and authoritative for their own jails. A hub is optional. The backup node never holds a key.

Architecture overview Operators use the CLI, SDK, web console or jailops-sync against the REST API. An optional hub forwards requests to hosts. Each host runs jailopsd and jails on ZFS and holds its own backup key. Hosts send encrypted chunks to a keyless backup node, which stores them in a directory or an S3 bucket. Fleet repositorygit, YAML, age secrets jailops-syncplan, apply, adopt jailops CLI, Go SDKweb consoles REST API, /1.0 Hub (optional)jailopsd in hub mode, forwards over pinned mTLS Hostjailopsd, jailops-privjails on ZFS, PF, VNETbackup key stays here Hostjailopsd, jailops-privjails on ZFS, PF, VNETbackup key stays here Hostjailopsd, jailops-privjails on ZFS, PF, VNETbackup key stays here encrypted, deduplicated chunks Backup node: jailops-backupdkeyless: holds no key, cannot decrypt Repository: a directory or an S3 bucket
  • The CLI, SDK, jailops-sync and the web consoles all use the same REST API. A host can be managed directly or through a hub.
  • If the hub is down, hosts keep working. Moving a jail between hosts is a cold move: there is no live migration.
  • The master key lives on the host. The backup node stores and verifies encrypted chunks; restores and deep verification run on a host that holds the key.

One CLI. One API. Every jail.

Your infrastructure. Your jail.

JailOps is pre-release software and is not ready for production use. Read what works today, then build it from source.

Get started Status and roadmap Source code