Hi Maxim, yes, it is fully automated. What happens is: - a server is provisioned through the Hetzner API - the the server is booted into the rescue system via the API - partitions are setup in the rescue system (enlarged) - a minimal Guix system is installed - then the server re-booted, starting the minimal Guix system - then the machine-ssh-environment takes over and applies the final system configuration - this all is done once, when the server is initially provisioned Previsouly I tried the guix-infect.sh approach that installs a Guix system on top of a debian/ubuntu image, but I found this was very brittle (issues with dns when you remove /etc, etc.). From my experience working with this I found the approach with the rescue system both more reliable and faster. Does this mnake sense? Roman Maxim Cournoyer writes: > Hi Roman, > > Roman Scherer writes: > > [...] > >> Things to improve another day: >> >> - Get Hetzner to add a Guix image to their collectin of supported images. That >> would remove the need for using the rescue system to install an initial Guix system. >> >> - Installing the initial Guix system via the rescue system is kind of slow >> (especially if there are no substituyes), and done in sequence. I'm not sure >> how this could be parallelized with how things are invoke by guix deploy. > > Forgive my ignorance, but I thought the idea of a deploy > environment type was to allow fully provisioning the OS via the service > API? > > I haven't reviewed the change yet; perhaps you mean that currently such > provision must happen by going through the rescue system path (but is > still automated by this new environment type?)