Lilith Semi - Systems

Infrastructure and systems for Lilith Semiconductor

Devices

Balthasar

EDIS Global US East box

• Public entrypoint

Melchior

Switzerland on-prem box

Casper

Southern California on-prem box

• Off-site backup target. Holds an append only restic copy of balthasar's identity database, mail, forge and Vaultwarden vault, on an encrypted three way ZFS mirror that balthasar cannot delete from
• The La Suite host since 2026-08-31. Docs, Drive and Meet run here, and the documents they hold have NO second copy anywhere. Read devices/casper/README.md before you touch a disk in this box

Services

Public

• git.lilithsemi.com, Forgejo, git over ssh + http(s)
• mail.lilithsemi.com: mail, no frontent

Private, served by balthasar

• auth.magi.lilithsemi.com: SSO authentication
• grafana.magi.lilithsemi.com: Grafana dashboard
• chat.magi.lilithsemi.com: Mattermost
• mail.magi.lilithsemi.com: Roundcube mail frontend
• pass.magi.lilithsemi.com: Vaultwarden
• vault.magi.lilithsemi.com: OpenBao
• ledger.magi.lilithsemi.com: Hledger

Private, served by casper

Balthasar answers these four names too, and it serves none of them. Balthasar holds the certificate, terminates the TLS, and proxies the request to casper over the mesh or the tailnet. Casper answers plain HTTP inside that tunnel. None of the four is reachable from the public internet.

• casper.magi.lilithsemi.com: the health route, /health. It proves the whole path with no application behind it
• docs.magi.lilithsemi.com: La Suite Docs
• drive.magi.lilithsemi.com: La Suite Drive
• meet.magi.lilithsemi.com: La Suite Meet, with LiveKit under /livekit

Layout

Path	Holds
flake.nix	Inputs, system helpers, treefmt, devshell
systems.nix	The host table
modules/	Shared modules. default.nix imports all of them
devices/<host>/	One host. default.nix imports the rest, README.md is its runbook
certs/	Public certificates only. Never a private key
tests/	NixOS VM tests, wired into nix flake check

A shared module with something to select gives an option under magi.*. A device turns on what it uses.

Working on it

nix develop
nix fmt
nix flake check --all-systems --no-build
nix eval .#nixosConfigurations.balthasar.config.system.build.toplevel.drvPath

All four, and in that order. Each of the last two catches something the other misses, and both are needed before any change is called done.

--all-systems, because plain nix flake check on an aarch64 workstation SKIPS every x86_64 output, so it never looks at balthasar at all and reports green.

--no-build, because without it the check tries to BUILD the x86_64 treefmt check under qemu, which segfaults. The workstation kernel uses 64K memory pages, x86_64 expects 4K, and qemu-user cannot present a finer mmap granularity than the host page size.

The nix eval line is the real gate for a host. flake check forces the toplevel far enough to run the NixOS assertion list, and it does NOT instantiate the derivation, so a hard option conflict can pass it. One did: caddy.startLimitIntervalSec was set twice with no mkForce, and only instantiating toplevel.drvPath found it.

Do not BUILD the closure on an aarch64 workstation. It cannot work, for the 64K page reason above.

balthasar builds its own system, over SSH, not the workstation. See step 12 of devices/balthasar/README.md for the full reason and the command. deploy-rs is wired into the flake (self.deploy.nodes.balthasar) for the day an x86_64 builder exists on the network. It builds locally, so it cannot deploy balthasar yet. Do not use it.