diff --git a/web/content/blog/2025-03-21-overlay-store/index.md b/web/content/blog/2025-03-21-overlay-store/index.md
index b7ee685ae..9c2b80f1f 100644
--- a/web/content/blog/2025-03-21-overlay-store/index.md
+++ b/web/content/blog/2025-03-21-overlay-store/index.md
@@ -14,18 +14,19 @@ homepage: false
 
 ## Background
 
-About a year ago, nix introduced a new experimental store type:
+About a year ago, Nix introduced a new experimental store type:
 [Local Overlay Store]. This store allows having multiple physical stores acting
 as a single logical store.
 
 With this approach, stores are layered on top of each other with all but the
-top-most layer being writable, the others are read-only. The feature is
-described in the [Upstream Nix Documentation][Local Overlay Store]. Work is
-[ongoing][lix-local-overlay] to bring the feature to Lix aswell.
+top-most layer being writable, the others are read-only. Nix will build inside
+the top-most layer.
+The feature is described in the [Upstream Nix Documentation][Local Overlay Store].
+Work is [ongoing][lix-local-overlay] to bring the feature to Lix aswell.
 
-The main use-case is for it is having a large nix store mounted onto a machine
-as read-only and configure nix to use data stored in it to avoid
-rebuilding/substituting from `cache.nixos.org`.
+The main use-case is for it is having a large Nix store mounted onto a machine
+as read-only and having Nix not rebuild/substitute store paths available in
+lower layers.
 
 Due to implementation details of this feature, the lower layer(s) can not only
 be a location on the file system but also have another `nix-daemon` back the
@@ -62,7 +63,7 @@ multiple `snix` components.
 
 Stay tuned.
 
-[castore]: https://snix.dev/docs/components/overview/
+[castore]: {{< ref "/docs/components/overview.md" >}}
 [bugs]: https://git.snix.dev/snix/snix/issues
 [Local Overlay Store]: https://nix.dev/manual/nix/2.26/store/types/experimental-local-overlay-store.html
 [replit]: https://blog.replit.com/tvix-store
diff --git a/web/content/docs/guides/local-overlay.md b/web/content/docs/guides/local-overlay.md
index 45dd3482d..6bb0dcbb5 100644
--- a/web/content/docs/guides/local-overlay.md
+++ b/web/content/docs/guides/local-overlay.md
@@ -39,7 +39,7 @@ You can run the daemon with:
 $ $(nix-build -A snix.snix-store)/bin/snix-store daemon
 ```
 
-### Mount the castore onto your file system
+### Mount the store
 
 To expose the store paths and their contents as a file system, if can be
 FUSE-mounted with the following command:
@@ -61,10 +61,25 @@ $ $(nix-build -A snix.nix-daemon)/bin/nix-daemon -l /tmp/snix-daemon.sock \
     --unix-listen-unlink
 ```
 
-This will launch the `snix` nix-daemon listening on a unix domain socket
+This will launch the `snix` nix-daemon listening on a unix domain socket.
+
+Nix will communicate with it to get metadata about store paths.
 
 ### Create an overlayfs mount
 
+{{<callout>}}
+Depending on your usecase, this might not be appropriate for a physical NixOS
+system, replacing `/nix` globally.
+
+In these cases, you want to ensure store paths needed to boot the system are
+available on the plain disk.
+
+You most likely want to mount this combined mountpoint elsewhere, and spin up a
+separate mount namespace (via `systemd-nspawn`, `bwrap` or similar) exposing it
+at `/nix` in there. You have been warned!
+{{</callout>}}
+
+
 Bind mount your real /nix store on the side, so that nix has direct access to
 it, this is optional but allows you to have access to your real nix store
 without unmounting:
@@ -108,11 +123,16 @@ This can be achieved by either setting the env variable
 
 ### Profit
 
-With the above setup you should now be able to have nix use Snix Castore as its
+With the above setup you should now be able to have nix use Snix castore as its
 lower store.
 
-Note that snix's FUSE mount might be performing slower than the native
-file-system depending on your workload. Please file bugs if you notice obviously
-bad performance.
+{{<callout>}}
+There are some known (and not yet worked-on) performance issues in Snix
+castore, which is why the mount is expected to perform slower than the native
+file-system. Depending on your workload, this might or might not be an issue.
 
+Check [our Bug tracker][castore-perf-issues] for updates on that topic.
+{{</callout>}}
+
+[castore-perf-issues]: https://git.snix.dev/snix/snix/issues?q=&type=all&sort=&labels=14%2c24
 [local overlay]: https://nix.dev/manual/nix/2.26/store/types/experimental-local-overlay-store.html