The State NixOS Won't Manage

Imagine bootstrapping your company’s entire internal infrastructure (Git servers, SSO, initial repositories, and user permissions) with one single command. Normally, NixOS will happily deploy Keycloak and Forgejo for you, but then you hit a wall: you still have to manually click through admin UIs, configure realms, and copy client secrets between them. This exposes a fundamental flaw in modern infrastructure: the imperative nature of application state. NixOS modules stop at the systemd unit on purpose: they manage the package, the config file, and the service, but not the state a service creates once it's running.

declarative-runtime is a tool to close that gap with pieces that already exist. Many of these services ship a Terraform provider for exactly this state, so it pairs a NixOS module with a provider through OpenTofu. You declare the runtime state in Nix, it generates the provider configuration, and a systemd oneshot unit reconciles it once the service is up. Secrets are passed in with LoadCredential so they never touch the world-readable store. It ships backends for Forgejo, Keycloak, Jellyfin, and Hetzner DNS today, with more on the way; the last of those shows the pattern reaches cloud resources too, not just a service's own internal state.

To make this concrete, the talk culminates in a live demo. We will wire Forgejo and Keycloak together for single sign-on using exactly one Nix configuration: no clicking, no copying secrets, and without ever opening an HCL file. We'll build it live, modify the infrastructure state, and rebuild, proving that the runtime state of two completely distinct services can move perfectly in sync, fully declaratively, with a single command.

Alexander Foremny

Nix/NixOS consultant at Applicative Systems.

Alexander Foremny is a longtime functional programming and Linux enthusiast.