linuxbrew-operator

A Kubernetes operator that reconciles BrewFormula custom resources by running Linuxbrew. Yes, really.

What

Declare a Homebrew formula as a Kubernetes resource. The operator installs it.

apiVersion: brew.coilysiren.me/v1alpha1
kind: BrewFormula
metadata:
  name: personal-dashboard
spec:
  tap: coilysiren/tap
  formula: personal-dashboard
  version: latest
  installTarget: pod

$ kubectl get brewformula
NAME                  FORMULA              VERSION   TARGET   PHASE   AGE
personal-dashboard    personal-dashboard   1.2.3     pod      Ready   3m

How

Two install targets, both in scope. Shipping pod first.

• installTarget: pod - the operator spawns an ephemeral Job using the official homebrew/brew image, runs brew install <tap>/<formula> into a PersistentVolumeClaim, then creates a Deployment that mounts the PVC and execs the brewed binary. Reproducible, no host privileges.
• installTarget: host - the operator drives a privileged DaemonSet that runs brew install against the node's Linuxbrew prefix and emits a systemd unit via nsenter. The cursed shape. Phase 2.

Status

v1alpha1, bootstrapping. Umbrella tracking at #1. Not yet usable.

Why

Because the niche was empty and the joke was too good to leave on the table. Filed origin: personal-dashboard#63.

Stack

• Go + Kubebuilder. Standard operator scaffold.
• Helm chart (forthcoming) at chart/ deploys the CRD + controller + RBAC.
• Tested against k3s on the host that owns the Linuxbrew prefix.

License

Apache 2.0.

See also

• AGENTS.md - agent-facing operating rules.
• docs/FEATURES.md - inventory of what ships today.
• .coily/coily.yaml - allowlisted commands.

Cross-reference convention from coilysiren/agentic-os#59.