URI: 

       Title: Managing a fleet of NixOS Part 3 - Welcome to Bento
       Author: Solène
       Date: 04 September 2022
       Tags: bento nixos nix
       Description: In this series of articles, I'll explain my steps toward
       designing an infrastructure to centrally manage a fleet of NixOS
       systems. The product is now alive and is called Bento.
       
       # Introducing Bento 🥳
       
       I finally wrote an implementation for the NixOS fleet management, it's
       called Bento.
       
  HTML Bento git project repository
       
       # Features
       
       * secure 🛡️: each client can only access its own configuration
       files (ssh authentication + sftp chroot)
       * efficient 🏂🏾: configurations can be built on the central
       management server to serve binary packages if it is used as a
       substituters by the clients
       * organized 💼: system administrators have all configurations files
       in one repository to easy management
       * peace of mind 🧘🏿: configurations validity can be verified
       locally by system administrators
       * smart 💡: secrets (arbitrary files) can (soon) be deployed without
       storing them in the nix store
       * robustness in mind 🦾: clients just need to connect to a remote
       ssh, there are many ways to bypass firewalls (corkscrew, VPN, Tor
       hidden service, I2P, ...)
       * extensible 🧰 🪡: you can change every component, if you prefer
       using GitHub repositories to fetch configuration files instead of a
       remote sftp server, you can change it
       * for all NixOS 💻🏭📱: it can be used for remote workstations,
       smartphones running NixoS, servers in a datacenter
       
       # Evolutions
       
       The project is still bare right now, I started it yesterday and I have
       many ideas to improve it:
       
       * package it to provide commands in `$PATH` instead of adding scripts
       to your config repository
       * add a rollback features in case an upgrade is losing connectivity
       * upgrades can depose a log file in the remote sftp server
       * upgrades could be triggered by the user by accessing a local socket,
       like opening a web page in a web browser to trigger it, if it returns
       output that'd be better
       * provide more useful modules in the utility nix file (automatically
       use the host as a binary cache for instance)
       * have a local information how to ssh to the client to ease the rebuild
       trigger (like a SSH file containing ssh command line)
       * a way to tell a client (when using flakes) to try to update flakes
       every time even if no configuration changed, to keep them up to date