How Janus works

Janus is a Linux distribution built from scratch around one job: running HAProxy. Its root filesystem is read-only and verified block by block (dm-verity), it boots a signed kernel image from one of two slots so an update can be rolled back, SELinux confines every daemon, and there is no shell to log into: a single daemon, janusd, serves the node’s whole API over gRPC with mutual TLS.

flowchart LR
    accTitle: How Janus's parts talk to each other
    accDescr: An operator uses the Controller's web UI or janusctl. Both reach each node's janusd over gRPC with mutual TLS on port 9505. janusd runs HAProxy and the optional extensions, which serve the clients' traffic. The Controller can also create nodes on libvirt or Proxmox VE hosts.
    op([Operator]) -->|HTTPS| ctrl["Controller (dashboardd)"]
    op --> cli[janusctl]
    ctrl -->|"gRPC + mTLS, port 9505"| janusd
    cli -->|"gRPC + mTLS, port 9505"| janusd
    ctrl -.->|"libvirt or Proxmox VE API"| hv[(Hypervisors)]
    subgraph node [Janus node]
        janusd --> haproxy[HAProxy]
        janusd --> ext["Extensions: nftables, keepalived, BIRD, Consul..."]
    end
    clients([Clients]) -->|"HTTP, TCP"| haproxy

In this section

• Architecture - the design: immutability and the A/B partition layout, trusted boot, the PKI, SELinux, the no-shell API, extensions.
• Boot and A/B updates - the disk, the boot chain from the firmware to the API, and an update step by step.
• Trust and certificates - who signs what, and what a node accepts.
• The Controller - its ports, the relay to the nodes, what it keeps, its background work.
• How an image is built - from pinned sources to a signed image and its update bundle.
• The gRPC API - every service and method, and which are implemented.
• Roadmap - how Janus was built, phase by phase, and what’s planned.
• The disk image, the ISO image and network boot - how the images are laid out and built.