Ooh, very neat. This always seems to me like one of the use cases something like nixos is best suited to, a large number of very simple systems that use GUIs and need to be maintained in the exact same way, but may be physically hard to get to.
Just stick NixOS on it, and have it use something like services.self-deploy. cage is also really cool, there are some really specific wayland compositors out there.
Always think about this when I see those bus displays that are forever rebooting Windows XP because a contractor didn’t look further than their nose 10 years ago 
TIL about self deploy, but I can’t really figure what it’s doing? With flakes now, I suppose using the self-deploy code in the flake input and using autoUpgrade would give the same result?
In NixOS, we also have a surf-display module, but I couldn’t get it to work. I need to investigate further but it seems broken 
and upstream last commit is from 5 years ago, so this project seems dead.
Actually, just using system.autoUpgrade.flake and pointing it at a git repo on the internet will do almost exactly the same thing.
self-deploy is just how you can do the workflow of “download latest version of a git branch and nixos-rebuild it” for traditional nix commands.
I have a fix for surf-display 
I’ll make a PR to fix it in nixpkgs, and update the blog post.
I use cage as well for a similar type of setup (chromium showing openHAB on an old surface tablet), but I use colmena for deployments, instead of having the device itself handle updates.
With multiple devices that would still just be a matter of colmena apply --on @kiosk and all tagged devices are updated.
Having been burned more than once in the past by self-updating systems, I much prefer to be in control of when it happens.
I think on the kind of kiosks I’m thinking of that may not be practical, e.g. when they’re driving around on a bus and only have network access for short periods. The “push” model doesn’t work too well in that kind of scenario.
I think @Solene 's own GitHub - rapenne-s/bento: A KISS deployment tool to keep your NixOS fleet (servers & workstations) up to date. might be better suited if you want something more sophisticated than the self-deploy/autoUpgrade modules.
Self-updating is absolutely a nightmare in the traditional sysadmin world, and has probably been for longer than I’ve been alive, so I completely understand the reluctance.
That said, I think NixOS’ purity and declarativeness actually make it feasible, especially on kiosk systems that should really not be storing any data. You can even perform automated tests before deployment. This is exactly why I think NixOS is such a good fit for the scenario.
colmena is much more suited to scenarios like yours, where the device should really always be up and listening, of course. There the “push” model makes sense, since it’s unlikely to fail. It also works better with fewer targets, because there is less pressure on the deploying host, and fewer places where small risks can occur.
This buys you better control of the deployment process and more immediate feedback, in exchange for less fault tolerance and scalability.
With NixOS there is a sort of middle ground between those two update methods, you can automatically pull/build the new config to the machine, but not switch. Then let someone manually trigger the switch.
This is great. @Solene – are there any other additions to a basic configuration.nix to get things working? e.g. enabling an xserver, etc.
The article says
Note that you need to disable any X server related configuration.
I don’t remember that something else is required, cage is using wayland IIRC so it runs from a tty, and the module is doing its magic.