Overhaul installation documentation

1 files changed, 11 insertions, 17 deletions

diff --git a/builds.sr.ht/installation.md b/builds.sr.ht/installation.md
index 54d3e2e..b8bc3ce 100644
--- a/builds.sr.ht/installation.md
+++ b/builds.sr.ht/installation.md
@@ -15,13 +15,8 @@ such](/installation.md). However, it is important that you configure *two* Redis
 servers - one that the runners should have access to, and one that they should
 not. Insert connection details for the former into build.sr.ht's configuration
 file under the `redis` key. Each build runner will also need a local redis
-instance running. In an insecure deployment (all services on the same server)
-you can get away with a single Redis instance.
-
-We suggest using an SSH tunnel to share the slave Redis instance between job
-runners and the master server, but you can use any method you prefer. If you use
-an SSH tunnel, you will likely want to use a reverse tunnel initiated from the
-master server, so the slaves are unable to SSH into the master server.
+instance running. In an insecure deployment (all services on the same server,
+running only trusted builds), you can get away with a single Redis instance.
 
 # Security model
 
@@ -95,17 +90,16 @@ necessary. It's recommended that you set up cron jobs to build fresh images
 frequently - a script at `contrib/submit_image_build` is provided for this
 purpose.
 
-Note: You will need nested virtualization enabled in order to build images
-from within a pre-existing build image (i.e. via the `build.yml` file). If you
-run into issues with `modprobe kvm_intel` within the genimg script, you can
-fix this by removing the module and then re-inserting it with `insmod
-kvm_intel.ko nested=1` in the directory containing the kernel module.
-
-### Image-specific notes
+**Note**: it is recommended that you modify our `build.yml` files to suit your
+instance's needs, then run it on *our* hosted builds.sr.ht instance to bootstrap
+your images. This is the fastest and most convenient way to bootstrap the images
+you need.
 
-* NixOS can be bootstrapped from any distribution. The provided build.yml does
-  it from Alpine, but it can be easily switched to eg. Archlinux just by
-  changing the host image and adjusting the packages.
+**Note**: You will need nested virtualization enabled in order to build images
+from within a pre-existing build image (i.e. via the `build.yml` file). If you
+run into issues with `modprobe kvm_intel` within the genimg script, you can fix
+this by removing the module and then re-inserting it with `insmod kvm_intel.ko
+nested=1` in the directory containing the kernel module.
 
 ## Creating new images