diff --git a/content/dev/site/devlog-1.md b/content/dev/site/devlog-1.md
index cd3d857..9bf22c8 100644
--- a/content/dev/site/devlog-1.md
+++ b/content/dev/site/devlog-1.md
@@ -11,7 +11,7 @@ now being powered by a web server [written in
 Rust](https://git.rustybever.be/Chewing_Bever/site-backend), powered by
 [Axum](https://github.com/tokio-rs/axum).
 
-The reason for this is expandibility. While nginx is really good at what it
+The reason for this is expandability. While nginx is really good at what it
 does, it's rather limited when it comes to implementing new features on top of
 it. However, even if it wasn't, I would've still switched because I just really
 wanted to work in Rust once more :D
diff --git a/content/dev/site/devlog-2.md b/content/dev/site/devlog-2.md
new file mode 100644
index 0000000..b5c5833
--- /dev/null
+++ b/content/dev/site/devlog-2.md
@@ -0,0 +1,46 @@
+---
+title: "Hosting arbitrary static sites"
+date: 2025-01-02T21:15:27+01:00
+tags: [rust, http, api]
+---
+
+The backend for this site currently serves four static sites: this blog and
+three Vieter sites, namely its [documentation](/docs/vieter), [API
+documentation](/api-docs/vieter) and [manpages](/man/vieter). These can be
+updated by POSTing tarballs containing the static files to the backend. This
+all works fine, but the API sucked and the four static sites were hardcoded,
+meaning it wasn't possible to add new sites without recompiling the backend.
+
+## The old API
+
+My original choice for this API was rather strange in my opinion. There was a
+single route, `/api/deploy`, where tarballs could be uploaded to, along with an
+optional query parameter specifying which of the sites the tarball contained.
+If the parameter was omitted, it defaulted to the "root site", meaning the
+blog.
+
+This design choice always felt strange to me, but I didn't care enough to
+change it. *Until now*.
+
+## In with the new
+
+The new design is in my opinion a lot more clean and straightforward. I can
+push a tarball to any route, e.g. `/docs/vieter` and the contents of the
+tarball will be mounted there. The server simply unpacks the tarball at the
+specified path and functions as a simple file server. Updating a directory
+overwrites its contents without checking if anything is overwritten, meaning I
+do need to watch out I don't accidentally publish sites to subdirectories of
+other sites. If I do, they will be removed every time the parent directory is
+updated.
+
+An important caveat here is the root directory. The above method would imply
+that updating `/` would overwrite all other sites every time, which is bad. To
+prevent this, a site uploaded to `/` (or `/_root`) is instead stored in `_root`
+on disk. When serving a file, the server first looks in the `/_root` directory
+first, and in the other directories if no file is found.
+
+This setup allows me to create as many static sites as I want and host them on
+subpaths of my domain with ease. I hope to use this feature some time this
+year!
+
+Jef