diff --git a/_snippets/recipe-standard-ingredients.md b/_snippets/recipe-standard-ingredients.md
index b9712d9..a6b6c7d 100644
--- a/_snippets/recipe-standard-ingredients.md
+++ b/_snippets/recipe-standard-ingredients.md
@@ -9,4 +9,4 @@
 
     Related:
 
-    * [X] [Traefik Forward Auth](ha-docker-swarm/traefik-forward-auth/) to secure your Traefik-exposed services with an additional layer of authentication
\ No newline at end of file
+    * [X] [Traefik Forward Auth](/ha-docker-swarm/traefik-forward-auth/) to secure your Traefik-exposed services with an additional layer of authentication
diff --git a/examples/scripts/gcb-aliases.sh b/examples/scripts/gcb-aliases.sh
index 095312f..a02a1a9 100644
--- a/examples/scripts/gcb-aliases.sh
+++ b/examples/scripts/gcb-aliases.sh
@@ -1,6 +1,6 @@
 alias dklc='docker ps -l'  # List last Docker container
 alias dklcid='docker ps -l -q'  # List last Docker container ID
-alias dklcip='docker inspect -f "{{.NetworkSettings.IPAddress}}" $(docker ps -l -q)'  # Get IP of last Docker container
+alias dklcip='docker inspect -f "{{range .NetworkSettings.Networks}}{{println .IPAddress}}{{end}}" $(docker ps -l -q)'  # Get IP's of last Docker container
 alias dkps='docker ps'  # List running Docker containers
 alias dkpsa='docker ps -a'  # List all Docker containers
 alias dki='docker images'  # List Docker images
@@ -14,5 +14,5 @@ alias dkideps='docker-image-dependencies'  # Output a graph of image dependencie
 alias dkre='docker-runtime-environment'  # List environmental variables of the supplied image ID
 alias dkelc='docker exec -it `dklcid` bash' # Enter last container (works with Docker 1.3 and above)
 alias git='docker run -v $PWD:/var/data -v /var/data/git-docker/data/.ssh:/root/.ssh funkypenguin/git-docker git' # Run git client in a container (for hosts witohut git)
-alias dsd='docker stack deploy "$1" -c /var/data/config/"$1"/"$1".yml
-alias dsr='docker stack rm "$1"
+alias dsd='docker stack deploy "$1" -c /var/data/config/"$1"/"$1".yml'
+alias dsr='docker stack rm "$1"'
diff --git a/manuscript/kubernetes/deployment/flux/design.md b/manuscript/kubernetes/deployment/flux/design.md
index 818d05e..ee9615e 100644
--- a/manuscript/kubernetes/deployment/flux/design.md
+++ b/manuscript/kubernetes/deployment/flux/design.md
@@ -38,7 +38,7 @@ Consider this entity relationship diagram:
 And here's what it all means, starting from the top...
 
 1. The flux-system **Kustomization** tells flux to look in the repo in `/flux-system`, and apply any YAMLs it finds (*with optional kustomize templating, if you're an uber-ninja!*).
-2. Within `/flux-system`, we've defined (for convenience), 3 subfolders, containing YAML for:
+2. Within `/bootstrap`, we've defined (for convenience), 3 subfolders, containing YAML for:
       1. `namespaces` : Any other **Namespaces** we want to deploy for our apps
       2. `helmrepositories` : Any **HelmRepositories** we later want to pull helm charts from
       3. `kustomizations` : An **Kustomizations** we need to tell flux to import YAMLs from **elsewhere** in the repository
diff --git a/manuscript/kubernetes/deployment/flux/install.md b/manuscript/kubernetes/deployment/flux/install.md
index 4849b35..626e0af 100644
--- a/manuscript/kubernetes/deployment/flux/install.md
+++ b/manuscript/kubernetes/deployment/flux/install.md
@@ -65,7 +65,7 @@ Create a GitHub [personal access token](https://github.com/settings/tokens) that
 
 ### Create GitHub Repo
 
-Now we'll create a repo for flux - it can (*and probably should!*) be private. I've created a [template repo to get you started](https://github.com/geek-cookbook/template-flux/generate), but you could simply start with a blank repo too.[^1]
+Now we'll create a repo for flux - it can (*and probably should!*) be private. I've created a [template repo to get you started](https://github.com/geek-cookbook/template-flux/generate), but you could simply start with a blank repo too (*although you'll need at least a `bootstrap` directory included or the command below will fail*).[^1]
 
 ### Bootstrap Flux
 
@@ -86,7 +86,8 @@ GITHUB_TOKEN=<your-token>
 flux bootstrap github \
   --owner=my-github-username \ 
   --repository=my-github-username/my-repository \
-  --personal
+  --personal \
+  --path bootstrap
 ```
 
 Once the flux bootstrap is completed without errors, list the pods in the cluster again, with `kubectl get pods -A`. This time, you see something like this:
@@ -115,12 +116,12 @@ Flux installed its controllers into the `flux-system` namespace, and created two
 
 If you used my template repo, some extra things also happened..
 
-1. I'd pre-populated the `flux-system` directory in the template repo with 3 folders:
-      1. [helmrepositories](https://github.com/geek-cookbook/template-flux/tree/main/flux-system/helmrepositories), for storing repositories used for deploying helm charts
-      2. [kustomizations](https://github.com/geek-cookbook/template-flux/tree/main/flux-system/kustomizations), for storing additional kustomizations *(which in turn can reference other paths in the repo*)
-      3. [namespaces](https://github.com/geek-cookbook/template-flux/tree/main/flux-system/namespaces), for storing namespace manifests (*since these need to exist before we can deploy helmreleases into them*)
-2. Because the `flux-system` Kustomization includes everything **recursively** under `flux-system` path in the repo, all of the above were **also** applied to the cluster
-3. I'd pre-prepared a [Namespace](https://github.com/geek-cookbook/template-flux/blob/main/flux-system/namespaces/namespace-podinfo.yaml), [HelmRepository](https://github.com/geek-cookbook/template-flux/blob/main/flux-system/helmrepositories/helmrepository-podinfo.yaml), and [Kustomization](https://github.com/geek-cookbook/template-flux/blob/main/flux-system/kustomizations/kustomization-podinfo.yaml) for "podinfo", a simple example application, so these were applied to the cluster
+1. I'd pre-populated the `bootstrap` directory in the template repo with 3 folders:
+      1. [helmrepositories](https://github.com/geek-cookbook/template-flux/tree/main/bootstrap/helmrepositories), for storing repositories used for deploying helm charts
+      2. [kustomizations](https://github.com/geek-cookbook/template-flux/tree/main/bootstrap/kustomizations), for storing additional kustomizations *(which in turn can reference other paths in the repo*)
+      3. [namespaces](https://github.com/geek-cookbook/template-flux/tree/main/bootstrap/namespaces), for storing namespace manifests (*since these need to exist before we can deploy helmreleases into them*)
+2. Because the `bootstrap` Kustomization includes everything **recursively** under `bootstrap` path in the repo, all of the above were **also** applied to the cluster
+3. I'd pre-prepared a [Namespace](https://github.com/geek-cookbook/template-flux/blob/main/bootstrap/namespaces/namespace-podinfo.yaml), [HelmRepository](https://github.com/geek-cookbook/template-flux/blob/main/bootstrap/helmrepositories/helmrepository-podinfo.yaml), and [Kustomization](https://github.com/geek-cookbook/template-flux/blob/main/bootstrap/kustomizations/kustomization-podinfo.yaml) for "podinfo", a simple example application, so these were applied to the cluster
 4. The kustomization we added for podinfo refers to the `/podinfo` path in the repo, so everything in **this** folder was **also** applied to the cluster
 5. In the `/podinfo` path of the repo is a [HelmRelease](https://github.com/geek-cookbook/template-flux/blob/main/podinfo/helmrelease-podinfo.yaml) (*an object describing how to deploy a helm chart*), and a [ConfigMap](https://github.com/geek-cookbook/template-flux/blob/main/podinfo/configmap-pofinfo-helm-chart-value-overrides-configmap.yaml) (*which ontain the `values.yaml` for the podinfo helm chart*)
 6. Flux recognized the podinfo **HelmRelease**, applied it along with the values in the **ConfigMap**, and consequently we have podinfo deployed from the latest helm chart, into the cluster, and managed by Flux! 💪
diff --git a/manuscript/kubernetes/deployment/flux/operate.md b/manuscript/kubernetes/deployment/flux/operate.md
index 9669ff9..0a60f07 100644
--- a/manuscript/kubernetes/deployment/flux/operate.md
+++ b/manuscript/kubernetes/deployment/flux/operate.md
@@ -12,7 +12,8 @@ We'll need 5 files per-app, to deploy and manage our apps using flux. The exampl
 
 ```hl_lines="4 6 8 10 11"
 ├── README.md
-├── flux-system
+├── bootstrap
+│   ├── flux-system
 │   ├── helmrepositories
 │   │   └── helmrepository-podinfo.yaml
 │   ├── kustomizations
@@ -40,7 +41,7 @@ Identify your target helm chart. Let's take podinfo as an example. Here's the [o
 ### Create HelmRepository
 
 The README instructs users to add the repo "podinfo" with the URL `ttps://stefanprodan.github.io/podinfo`, so
-create a suitable HelmRepository YAML in `flux-system/helmrepositories/helmrepository-podinfo.yaml`. Here's [my example](https://github.com/geek-cookbook/template-flux/blob/main/flux-system/helmrepositories/helmrepository-podinfo.yaml).
+create a suitable HelmRepository YAML in `bootstrap/helmrepositories/helmrepository-podinfo.yaml`. Here's [my example](https://github.com/geek-cookbook/template-flux/blob/main/bootstrap/helmrepositories/helmrepository-podinfo.yaml).
 
 !!! question "Why such obtuse file names?"
     > Why not just call the HelmRepository YAML `podinfo.yaml`? Why prefix the filename with the API object `helmrepository-`?
@@ -49,7 +50,7 @@ create a suitable HelmRepository YAML in `flux-system/helmrepositories/helmrepos
 
 ### Create Namespace
 
-Create a namespace for the chart. Typically you'd name this the same as your chart name. Here's [my namespace-podinfo.yaml](https://github.com/geek-cookbook/template-flux/blob/main/flux-system/namespaces/namespace-podinfo.yaml).
+Create a namespace for the chart. Typically you'd name this the same as your chart name. Here's [my namespace-podinfo.yaml](https://github.com/geek-cookbook/template-flux/blob/main/bootstrap/namespaces/namespace-podinfo.yaml).
 
 ??? example "Here's an example Namespace..."
 
@@ -62,7 +63,7 @@ Create a namespace for the chart. Typically you'd name this the same as your cha
 
 ### Create Kustomization
 
-Create a kustomization for the chart, pointing flux to a path in the repo where the chart-specific YAMLs will be found. Here's my [kustomization-podinfo.yaml](https://github.com/geek-cookbook/template-flux/blob/main/flux-system/kustomizations/kustomization-podinfo.yaml).
+Create a kustomization for the chart, pointing flux to a path in the repo where the chart-specific YAMLs will be found. Here's my [kustomization-podinfo.yaml](https://github.com/geek-cookbook/template-flux/blob/main/bootstrap/kustomizations/kustomization-podinfo.yaml).
 
 ??? example "Here's an example Kustomization..."
 
diff --git a/manuscript/kubernetes/external-dns.md b/manuscript/kubernetes/external-dns.md
index e710860..40894af 100644
--- a/manuscript/kubernetes/external-dns.md
+++ b/manuscript/kubernetes/external-dns.md
@@ -16,7 +16,7 @@ ExternalDNS is a controller for Kubernetes which watches the objects you create
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-external-dns.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-external-dns.yaml`:
 
 ??? example "Example Namespace (click to expand)"
 
@@ -29,7 +29,7 @@ metadata:
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-external-dns.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-external-dns.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -45,7 +45,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*just the HelmRepository in this case*z*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/external-dns`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-external-dns.yaml`:
+Now that the "global" elements of this deployment (*just the HelmRepository in this case*z*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/external-dns`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-external-dns.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/ingress/index.md b/manuscript/kubernetes/ingress/index.md
index 414239b..cd68c66 100644
--- a/manuscript/kubernetes/ingress/index.md
+++ b/manuscript/kubernetes/ingress/index.md
@@ -16,4 +16,4 @@ Choose at least one of the above (*there may be valid reasons to use both!* [^1]
   
 --8<-- "recipe-footer.md"
 
-[^1]: One cluster I manage uses traefik Traefik for public services, but Nginx for internal managemnet services such as Prometheus, etc. The idea is that you'd need one type of Ingress to help debug problems with the _other_ type!
+[^1]: One cluster I manage uses traefik Traefik for public services, but Nginx for internal management services such as Prometheus, etc. The idea is that you'd need one type of Ingress to help debug problems with the _other_ type!
diff --git a/manuscript/kubernetes/ingress/nginx.md b/manuscript/kubernetes/ingress/nginx.md
index 74334e4..a39669b 100644
--- a/manuscript/kubernetes/ingress/nginx.md
+++ b/manuscript/kubernetes/ingress/nginx.md
@@ -24,7 +24,7 @@ Nginx Ingress Controller does make for a nice, simple "default" Ingress controll
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-nginx-ingress-controller.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-nginx-ingress-controller.yaml`:
 
 ??? example "Example NameSpace (click to expand)"
     ```yaml
@@ -36,7 +36,7 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-bitnami.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-bitnami.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -52,7 +52,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/nginx-ingress-controller`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-nginx-ingress-controller.yaml`:
+Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/nginx-ingress-controller`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-nginx-ingress-controller.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/ingress/traefik/index.md b/manuscript/kubernetes/ingress/traefik/index.md
index 15fbb36..2daf3b8 100644
--- a/manuscript/kubernetes/ingress/traefik/index.md
+++ b/manuscript/kubernetes/ingress/traefik/index.md
@@ -25,7 +25,7 @@ Traefik natively includes some features which Nginx lacks:
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-traefik.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-traefik.yaml`:
 
 ??? example "Example NameSpace (click to expand)"
     ```yaml
@@ -37,7 +37,7 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the official [Traefik helm chart](https://github.com/traefik/traefik-helm-chart), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-traefik.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the official [Traefik helm chart](https://github.com/traefik/traefik-helm-chart), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-traefik.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -53,7 +53,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/traefik`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-traefik.yaml`:
+Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/traefik`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-traefik.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/loadbalancer/metallb/index.md b/manuscript/kubernetes/loadbalancer/metallb/index.md
index 785c3ea..7e21d4b 100644
--- a/manuscript/kubernetes/loadbalancer/metallb/index.md
+++ b/manuscript/kubernetes/loadbalancer/metallb/index.md
@@ -31,7 +31,7 @@ You'll need to make some decisions re IP allocations.
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-metallb.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-metallb-system.yaml`:
 
 ??? example "Example NameSpace (click to expand)"
     ```yaml
@@ -43,7 +43,7 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-bitnami.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the (*prolific*) [bitnami chart repository](https://github.com/bitnami/charts/tree/master/bitnami), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-bitnami.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -59,7 +59,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/metallb-system`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-metallb.yaml`:
+Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/metallb-system`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-metallb.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
@@ -92,7 +92,7 @@ Now that the "global" elements of this deployment (*Namespace and HelmRepository
 
 ### ConfigMap (for HelmRelease)
 
-Now we're into the metallb-specific YAMLs. First, we create a ConfigMap, containing the entire contents of the helm chart's [values.yaml](https://github.com/bitnami/charts/blob/master/bitnami/metallb/values.yaml). Paste the values into a `values.yaml` key as illustrated below, indented 4 tabs (*since they're "encapsulated" within the ConfigMap YAML*). I create this in my flux repo at `metallb/configmap-metallb-helm-chart-value-overrides.yaml`:
+Now we're into the metallb-specific YAMLs. First, we create a ConfigMap, containing the entire contents of the helm chart's [values.yaml](https://github.com/bitnami/charts/blob/master/bitnami/metallb/values.yaml). Paste the values into a `values.yaml` key as illustrated below, indented 4 tabs (*since they're "encapsulated" within the ConfigMap YAML*). I create this in my flux repo at `metallb-system/configmap-metallb-helm-chart-value-overrides.yaml`:
 
 ??? example "Example ConfigMap (click to expand)"
     ```yaml
@@ -148,7 +148,7 @@ Then work your way through the values you pasted, and change any which are speci
 
 ### ConfigMap (for MetalLB)
 
-Finally, it's time to actually configure MetalLB! As discussed above, I prefer to configure the helm chart to apply config from an existing ConfigMap, so that I isolate my application configuration from my chart configuration (*and make tracking changes easier*). In my setup, I'm using BGP against a pair of pfsense[^1] firewalls, so per the [official docs](https://metallb.universe.tf/configuration/), I use the following configuration, saved in my flux repo as `flux-system/configmap-metallb-config.yaml`:
+Finally, it's time to actually configure MetalLB! As discussed above, I prefer to configure the helm chart to apply config from an existing ConfigMap, so that I isolate my application configuration from my chart configuration (*and make tracking changes easier*). In my setup, I'm using BGP against a pair of pfsense[^1] firewalls, so per the [official docs](https://metallb.universe.tf/configuration/), I use the following configuration, saved in my flux repo as `metallb-system/configmap-metallb-config.yaml`:
 
 ??? example "Example ConfigMap (click to expand)"
     ```yaml
@@ -191,14 +191,14 @@ Finally, it's time to actually configure MetalLB! As discussed above, I prefer t
       config: |
         address-pools:
         - name: default
-        protocol: layer2
-        addresses:
-        - 192.168.1.240-192.168.1.250
+          protocol: layer2
+          addresses:
+          - 192.168.1.240-192.168.1.250
     ```
 
 ### HelmRelease
 
-Lastly, having set the scene above, we define the HelmRelease which will actually deploy MetalLB into the cluster, with the config and extra ConfigMap we defined above. I save this in my flux repo as `metallb/helmrelease-metallb.yaml`:
+Lastly, having set the scene above, we define the HelmRelease which will actually deploy MetalLB into the cluster, with the config and extra ConfigMap we defined above. I save this in my flux repo as `metallb-system/helmrelease-metallb.yaml`:
 
 ??? example "Example HelmRelease (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/persistence/topolvm.md b/manuscript/kubernetes/persistence/topolvm.md
index 815435b..d42e738 100644
--- a/manuscript/kubernetes/persistence/topolvm.md
+++ b/manuscript/kubernetes/persistence/topolvm.md
@@ -34,7 +34,7 @@ vgcreate VG-topolvm /dev/sdb
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-topolvm.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-topolvm.yaml`:
 
 ??? example "Example NameSpace (click to expand)"
     ```yaml
@@ -46,7 +46,7 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the official [TopoLVM helm chart](https://github.com/topolvm/topolvm/tree/main/charts/topolvm), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-topolvm.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. In this case, we're using the official [TopoLVM helm chart](https://github.com/topolvm/topolvm/tree/main/charts/topolvm), so per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-topolvm.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -62,7 +62,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/topolvm`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-topolvm.yaml`:
+Now that the "global" elements of this deployment (*Namespace and HelmRepository*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/topolvm`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-topolvm.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/sealed-secrets.md b/manuscript/kubernetes/sealed-secrets.md
index 02f157e..84e2ac9 100644
--- a/manuscript/kubernetes/sealed-secrets.md
+++ b/manuscript/kubernetes/sealed-secrets.md
@@ -52,7 +52,7 @@ A "[SealedSecret](https://github.com/bitnami-labs/sealed-secrets)" can only be d
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-sealed-secrets.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-sealed-secrets.yaml`:
 
 ??? example "Example Namespace (click to expand)"
     ```yaml
@@ -64,7 +64,7 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-sealedsecrets.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-sealedsecrets.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -80,7 +80,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*just the HelmRepository in this case*z*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/sealed-secrets`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-sealed-secrets.yaml`:
+Now that the "global" elements of this deployment (*just the HelmRepository in this case*z*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/sealed-secrets`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-sealed-secrets.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/ssl-certificates/cert-manager.md b/manuscript/kubernetes/ssl-certificates/cert-manager.md
index 9469678..3823750 100644
--- a/manuscript/kubernetes/ssl-certificates/cert-manager.md
+++ b/manuscript/kubernetes/ssl-certificates/cert-manager.md
@@ -22,7 +22,7 @@ It will ensure certificates are valid and up to date, and attempt to renew certi
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-cert-manager.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-cert-manager.yaml`:
 
 ??? example "Example Namespace (click to expand)"
     ```yaml
@@ -34,7 +34,7 @@ We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Pe
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-jetstack.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-jetstack.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -50,7 +50,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment (*just the HelmRepository in this case*z*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/cert-manager`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-cert-manager.yaml`:
+Now that the "global" elements of this deployment (*just the HelmRepository in this case*z*) have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/cert-manager`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-cert-manager.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/ssl-certificates/secret-replicator.md b/manuscript/kubernetes/ssl-certificates/secret-replicator.md
index bc90834..cb71381 100644
--- a/manuscript/kubernetes/ssl-certificates/secret-replicator.md
+++ b/manuscript/kubernetes/ssl-certificates/secret-replicator.md
@@ -15,7 +15,7 @@ Kiwigrid's "[Secret Replicator](https://github.com/kiwigrid/secret-replicator)"
 
 ### Namespace
 
-We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-secret-replicator.yaml`:
+We need a namespace to deploy our HelmRelease and associated ConfigMaps into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-secret-replicator.yaml`:
 
 ??? example "Example Namespace (click to expand)"
 
@@ -28,7 +28,7 @@ metadata:
 
 ### HelmRepository
 
-Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/helmrepositories/helmrepository-kiwigrid.yaml`:
+Next, we need to define a HelmRepository (*a repository of helm charts*), to which we'll refer when we create the HelmRelease. We only need to do this once per-repository. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/helmrepositories/helmrepository-kiwigrid.yaml`:
 
 ??? example "Example HelmRepository (click to expand)"
     ```yaml
@@ -44,7 +44,7 @@ Next, we need to define a HelmRepository (*a repository of helm charts*), to whi
 
 ### Kustomization
 
-Now that the "global" elements of this deployment have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/secret-replicator`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-secret-replicator.yaml`:
+Now that the "global" elements of this deployment have been defined, we do some "flux-ception", and go one layer deeper, adding another Kustomization, telling flux to deploy any YAMLs found in the repo at `/secret-replicator`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-secret-replicator.yaml`:
 
 ??? example "Example Kustomization (click to expand)"
     ```yaml
diff --git a/manuscript/kubernetes/ssl-certificates/wildcard-certificate.md b/manuscript/kubernetes/ssl-certificates/wildcard-certificate.md
index 40795e6..5835353 100644
--- a/manuscript/kubernetes/ssl-certificates/wildcard-certificate.md
+++ b/manuscript/kubernetes/ssl-certificates/wildcard-certificate.md
@@ -22,7 +22,7 @@ To take advantage of the various workarounds available, I find it best to put th
 
 ### Namespace
 
-We need a namespace to deploy our certificates and associated secrets into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `flux-system/namespaces/namespace-letsencrypt-wildcard-cert.yaml`:
+We need a namespace to deploy our certificates and associated secrets into. Per the [flux design](/kubernetes/deployment/flux/), I create this in my flux repo at `bootstrap/namespaces/namespace-letsencrypt-wildcard-cert.yaml`:
 
 ??? example "Example Namespace (click to expand)"
     ```yaml
@@ -34,7 +34,7 @@ We need a namespace to deploy our certificates and associated secrets into. Per
 
 ### Kustomization
 
-Now we need a kustomization to tell Flux to install any YAMLs it finds in `/letsencrypt-wildcard-cert`. I create this Kustomization in my flux repo at `flux-system/kustomizations/kustomization-letsencrypt-wildcard-cert.yaml`.
+Now we need a kustomization to tell Flux to install any YAMLs it finds in `/letsencrypt-wildcard-cert`. I create this Kustomization in my flux repo at `bootstrap/kustomizations/kustomization-letsencrypt-wildcard-cert.yaml`.
 
 !!! tip
     Importantly, note that we define a **dependsOn**, to tell Flux not to try to reconcile this kustomization before the cert-manager and sealedsecrets kustomizations are reconciled. Cert-manager creates the CRDs used to define certificates, so prior to Cert Manager being installed, the cluster won't know what to do with the ClusterIssuers/Certificate resources.
diff --git a/manuscript/recipes/autopirate/readarr.md b/manuscript/recipes/autopirate/readarr.md
index a4e69bb..d8df30d 100644
--- a/manuscript/recipes/autopirate/readarr.md
+++ b/manuscript/recipes/autopirate/readarr.md
@@ -29,7 +29,7 @@ Features include:
 To include Readarr in your [AutoPirate][autopirate] stack, include something like the following in your autopirate.yml stack definition file:
 
 ```yaml
-radarr:
+readarr:
   image: lscr.io/linuxserver/readarr:latest
   env_file : /var/data/config/autopirate/readarr.env
   volumes:
diff --git a/manuscript/reference/networks.md b/manuscript/reference/networks.md
index f798e80..8b5390f 100644
--- a/manuscript/reference/networks.md
+++ b/manuscript/reference/networks.md
@@ -12,10 +12,8 @@ In order to avoid IP addressing conflicts as we bring swarm networks up/down, we
 | [NightScout](https://geek-cookbook.funkypenguin.co.nz/recipes/nightscout/)                                            | 172.16.4.0/24  |
 | [Tiny Tiny RSS](https://geek-cookbook.funkypenguin.co.nz/recipes/tiny-tiny-rss/)                                      | 172.16.5.0/24  |
 | [Huginn](https://geek-cookbook.funkypenguin.co.nz/recipes/huginn/)                                                    | 172.16.6.0/24  |
-| [Gollum](https://geek-cookbook.funkypenguin.co.nz/recipes/gollum/)                                                    | 
-172.16.7.0/24  |
-| [Polr](https://geek-cookbook.funkypenguin.co.nz/recipes/polr/)                                                        | 
-172.16.9.0/24  |
+| [Gollum](https://geek-cookbook.funkypenguin.co.nz/recipes/gollum/)                                                    | 172.16.7.0/24  |
+| [Polr](https://geek-cookbook.funkypenguin.co.nz/recipes/polr/)                                                        | 172.16.9.0/24  |
 | [Duplicity](https://geek-cookbook.funkypenguin.co.nz/recipes/duplicity/)                                              | 172.16.10.0/24 |
 | [Autopirate](https://geek-cookbook.funkypenguin.co.nz/recipes/autopirate/)                                            | 172.16.11.0/24 |
 | [Nextcloud](https://geek-cookbook.funkypenguin.co.nz/recipes/nextcloud/)                                              | 172.16.12.0/24 |