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

Open
opened 2026-07-28 21:24:11 +01:00 by vnprc-agent · 1 comment

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.
Author

Superseded in part. The first goal here — a service archetype class — is now owned by allod/strategy#45 and allod/strategy/dev-plans/managed-service-machines.md, which is the source of truth for managed service machine architecture.

Two things changed since this was written.

A service archetype was built against the shape described here, reviewed four times, and abandoned — allod/archetypes#60, closed as not planned. The finding was that a builder in this repo is the join of inventory, secrets, and profiles, and the machine it was being built for had none of the three legs.

allod/strategy#45 then re-approaches it from the other end: generalise inventory around a discriminated placement first (its M2), so mkService has something honest to read, and make the archetype application-agnostic rather than shaped around one consumer (its M3). That plan also states directly that dev-plans/buzz-service-archetype.md must not be executed as written, because its VM-only inventory and application-specific archetype assumptions are superseded.

What survives here and is not tracked elsewhere: the buzz package at a pinned rev, the relay service module with its production-hardened defaults, the sizing and listener facts in "Current state", and the synthetic example machine. That work resumes as a consumer of the interfaces allod/strategy#45 defines, not as the thing that defines them.

Leaving this open rather than closing it — allod/strategy#45 M5 owns the decision to rebase this work or close it as superseded, and that milestone has not started.

Superseded in part. The first goal here — a `service` archetype class — is now owned by `allod/strategy#45` and `allod/strategy/dev-plans/managed-service-machines.md`, which is the source of truth for managed service machine architecture. Two things changed since this was written. A `service` archetype was built against the shape described here, reviewed four times, and abandoned — `allod/archetypes#60`, closed as not planned. The finding was that a builder in this repo is the join of inventory, secrets, and profiles, and the machine it was being built for had none of the three legs. `allod/strategy#45` then re-approaches it from the other end: generalise inventory around a discriminated placement first (its M2), so `mkService` has something honest to read, and make the archetype application-agnostic rather than shaped around one consumer (its M3). That plan also states directly that `dev-plans/buzz-service-archetype.md` must not be executed as written, because its VM-only inventory and application-specific archetype assumptions are superseded. What survives here and is not tracked elsewhere: the buzz package at a pinned rev, the relay service module with its production-hardened defaults, the sizing and listener facts in "Current state", and the synthetic example machine. That work resumes as a consumer of the interfaces `allod/strategy#45` defines, not as the thing that defines them. Leaving this open rather than closing it — `allod/strategy#45` M5 owns the decision to rebase this work or close it as superseded, and that milestone has not started.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
allod/archetypes#15
No description provided.