Since NixOS is Unix-like system, with a text based interface, and configuration in one file, can LLM fully automate it?
I’m just a casual NixOS user (mid-level at best), and I don’t have any working prototype yet - only a very concrete idea that I can’t get out of my head. The thought is extremely simple:
Machine A (the “brain”): a beefy server/desktop that only runs a local LLM (Llama, Qwen-2).
Machine B (the “body”): a completely separate NixOS machine that does all the real work.
The LLM on Machine A is the only administrator of Machine B. Interaction happens exclusively over SSH + a tiny privileged agent that can:
Pull the current flake or configuration.nix
Pull recent journalctl / dmesg / failed units
Accept my natural-language request (“add Tailscale with exit-node”, “install Ollama and expose it via nginx with HTTPS”, “why is Docker not starting after the last reboot?”)
Generate only the diff/patch
Run nixos-rebuild dry-activate and show me exactly what will change
On my “yes, apply” - run nixos-rebuild switch
If anything fails or the health-check script reports problems in the next few minutes - automatic nixos-rebuild switch --rollback
Because it’s NixOS, the rollback is instantaneous and 100 % reliable — the worst thing that can happen is we lose one generation and are back exactly where we started. I believe that in 2025 this loop is already technically solvable today with zero exotic tech — just local LLM + SSH + the usual NixOS guarantees. My questions to the community: Has anyone already built exactly this separation (LLM host / NixOS target) or something very close?
Are there existing open-source agents, NixOS modules or flakes that already do most of the pieces (safe apply + auto-rollback on failure)? My best bet is n8n as automation platform.
What obvious footguns am I missing (apart from the classic ‘the model deletes your SSH key’ scenario)?
I’m seriously considering building the minimal version sometime soon if no one else ever had this idea. Curious if I’m late to the party or if this is still unexplored territory. Or am I just this crazy and this is totally science fiction territory? Thanks!
Speaking of what can break the fully-safe ideal: some state management (cleaning up stale data of specific services) needs actually deleting things locally, and getting to do this management requires privileged access.
I’ve experimented lightly with things like this. LMs aren’t there yet for Nix/NixOS in my experience, but they’re getting there.
Seems the best way to make them sort of useful is to put a local copy of the manuals in RAG and give them access to a local checkout of nixpkgs for referncing. Generally, search tools just seem to make them hallucinate even more in my experience.
However, a word of caution:
The worst thing that can happen is we lose one generation and are back exactly where we started.
This is a bit of a lie we tell to kids. In reality, aside from just the config (which Nix gives you rollback for), there is also the state of databases and such, as well as distributed state (e.g., if you are running any distributed systems — think Matrix protocol, Fediverse, things like that).
Thus, the realistically best guarantee you can actually get is Nix + file-system snapshots for rollback of local-state and config. But there doesn’t seem to be any general purpose hammer that you can hit distributed state with yet to give you rollback: worth keeping in mind!
EDIT: Also my bar for “getting there” might be very high compared to what might constitute “good enough”, so I’d not discourage trying to make it work for you!
EDIT-2: And also, the real work is likely gonna be not in building out the LM part, but building out your own config to have strong enough testing (e.g VM tests of major modules and interactions) go let a LM run loose on it, more than anything else.
I have seen (in PRs I have merged) an inexperienced user ask CoPilot for a review, very reasonably dismiss half (because it’s pointless and/or misguided) but also force-push with the rest of the CoPilot suggestions applied (and I agree those were useful reminders). But probably an ability to correct the diff manually is still needed…
