Add service archetype for always-on LAN service VMs (first consumer: buzz relay stack) #15

New issue

Open

opened 2026-07-28 21:24:11 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-28 21:24:11 +01:00

Add a service archetype so the framework can compose small headless always-on VMs that serve other machines on the local network, with the buzz relay stack as the first consumer.

Primary goals:

Service archetype — a third archetype class beside dev and privacy: headless, always-on, fail-closed firewall with an explicit per-machine port allowlist, no forge write capability by default, standard rebuild-from-clone lifecycle.
Buzz stack module and package — a nix package for the buzz relay and CLI (Apache-2.0) at a pinned upstream rev, composed with native NixOS Postgres/Redis/MinIO modules — no containers.
Production-hardened defaults — the module requires a relay signing key (failing loud when it is absent without aborting activation) and enables REST token auth; upstream dev-mode defaults (hardcoded keypair, auth off) never reach a built machine.
Example machine — one synthetic service profile in the profiles input, buildable by strangers per the public-repo standard.
Fail-closed checks — composition checks for the new class; platforms derive from inventory.lib.supportedPlatforms, never local system lists.

Current state

The archetype layer stubs this class today: flake.nix:298 carries # mkServiceVm = TBD when first service VM is added. Evaluation numbers for sizing the first consumer: the buzz stack idles around 225MB total (relay 34MB, Postgres 30MB, Redis 9MB, MinIO 152MB). Relay behaviors the module must own: S3 is mandatory at boot (a git object-store conformance probe gates startup), search defaults to Postgres FTS so no extra search service is needed, and the relay binds a WebSocket/web port plus separate health (8080) and metrics (9102) listeners, so the archetype firewall must scope exposure per machine.

Scope

In scope: archetype merge support and shared modules for the service class, the buzz package and service module, one synthetic example machine, and checks — all in this repo and its profiles input. Out of scope, owned by downstream deploy forks: concrete machines and addressing, key material, backups, and rollout sequencing. The public dev plan for this work lands in allod/strategy dev-plans and links back here.

Add a service archetype so the framework can compose small headless always-on VMs that serve other machines on the local network, with the buzz relay stack as the first consumer. Primary goals: - **Service archetype** — a third archetype class beside dev and privacy: headless, always-on, fail-closed firewall with an explicit per-machine port allowlist, no forge write capability by default, standard rebuild-from-clone lifecycle. - **Buzz stack module and package** — a nix package for the [buzz](https://github.com/block/buzz) relay and CLI (Apache-2.0) at a pinned upstream rev, composed with native NixOS Postgres/Redis/MinIO modules — no containers. - **Production-hardened defaults** — the module requires a relay signing key (failing loud when it is absent without aborting activation) and enables REST token auth; upstream dev-mode defaults (hardcoded keypair, auth off) never reach a built machine. - **Example machine** — one synthetic service profile in the profiles input, buildable by strangers per the public-repo standard. - **Fail-closed checks** — composition checks for the new class; platforms derive from `inventory.lib.supportedPlatforms`, never local system lists. ### Current state The archetype layer stubs this class today: `flake.nix:298` carries `# mkServiceVm = TBD when first service VM is added`. Evaluation numbers for sizing the first consumer: the buzz stack idles around 225MB total (relay 34MB, Postgres 30MB, Redis 9MB, MinIO 152MB). Relay behaviors the module must own: S3 is mandatory at boot (a git object-store conformance probe gates startup), search defaults to Postgres FTS so no extra search service is needed, and the relay binds a WebSocket/web port plus separate health (8080) and metrics (9102) listeners, so the archetype firewall must scope exposure per machine. ### Scope In scope: archetype merge support and shared modules for the service class, the buzz package and service module, one synthetic example machine, and checks — all in this repo and its profiles input. Out of scope, owned by downstream deploy forks: concrete machines and addressing, key material, backups, and rollout sequencing. The public dev plan for this work lands in allod/strategy dev-plans and links back here.