Tired of SSH-ing into every NixOS machine to run updates? New guide on how to automate it: CI updates flake.lock daily, shows you exactly what changed per host, and machines self-upgrade after you merge. No surprises, no manual SSH.

Works also for your desktop machines.

https://getnix.io/guides/nixos-auto-upgrades/

#Nix #NixOS #CI #IaC #GitOps

Automatic NixOS Upgrades with Forgejo Actions

Keep NixOS servers and desktops up-to-date automatically — CI updates flake.lock, hosts self-upgrade daily, and you review a diff before anything deploys.

One potential optimization for the automatic NixOS upgrade via CI is to avoid creating a pull request if the flake update doesn’t impact any installed software.

In such cases, the update would only modify the flake.lock file, leaving the actual state of the machines unchanged.

@obale
This is awesome! Thanks for sharing.

Will definitely try to implement that when I get around to it

@betaigeuze I am glad it is helpful.
@obale With Forgejo Actions?! Sounds very interesting! Currently I'm updating my flake from time to time manually. The only obstacle I have is that it's a single flake for my laptop + 3 servers. I'd have to split it then (at least for the laptop).

@cameo007 Same for me. I have my laptops split from the servers. Both repositories use the same CI job logic. Thinking of splitting up overlays that overwrite software versions from both of them. Given that some of them are shared across the two repositories.

That was kind of the motivation to automate the update process. Got tired of it.

@obale very nice guide! I'll try the approach. The aspect of the review as a gate for the auto update is key from my perspective.

I guess this could be combined with a binary cache and the machine updates would be very quick operations, since everything has already been built.

Thanks for sharing this 👍

@obale
This is really cool❤️. I always love the approach of systems fetching the state rather than us applying the state manually to each one.
I wish pushing the commit & PR part is easier like GitHub actions.

Doubt:
does the diff show for each system ?

Also checkout this cool tool if u haven't yet: https://github.com/faukah/dix
(iirc this is used under the hood of nh too)

The next steps for u might be to monitor any system fail and automatically revert the systems to older state automatically 😅

@vivekanandanks I agree. The system fetching the state is a good design choice, especially also from a security perspective.

The diff is shown for each system (host). That was one of the main motivation factors to implement the automation in the first place. It uses nvd. How does dix differ?

Forgejo may have an easier way of implementing the commit/PR logic. The overcomplications may be my fault. Will look into it and if there is an easier way, update the article.

Thank you!

@obale
I haven't used nvd or dix directly. I use nh and it used nvd in the past and now uses dix iirc. I think the difference is the speed from what dix says in it's readme