Add 7 illustration links to guides-oct batch 2

blueprints/autostart-internal-apps.html.md

@@ -4,6 +4,10 @@ layout: docs
 nav: guides
 ---
 
+<figure>
+  <img src="/static/images/autostart-internal-apps.png" alt="Illustration by Annie Ruygt of Frankie the balloon having a picnic with an app and eating strawberries" class="w-full max-w-lg mx-auto">
+</figure>
+
 You have a private, or internal, app that communicates only with other apps on your [private network](/docs/networking/private-networking/). This private app might be a database, authentication server, or any other "backend" app that you don't want exposed to the public Internet. You want the app's Machines to stop when they're not serving requests from your other apps, and start again automatically when needed.
 
 To use Fly Proxy autostop/autostart you need to configure services in `fly.toml`, like you would for a public app. But instead of using a public Anycast address, you assign a Flycast address to expose those services only on your private network.

blueprints/connecting-to-user-machines.html.md

@@ -5,6 +5,10 @@ nav: guides
 date: 2025-04-02
 ---
 
+<figure>
+  <img src="/static/images/connecting-to-users.png" alt="Illustration by Annie Ruygt of a bird holding hands with a computer" class="w-full max-w-lg mx-auto">
+</figure>
+
 # Connecting to User Machines
 
 When running machines for end users, a common challenge is efficiently managing and routing requests to these machines. This document outlines the recommended approach for connecting to user machines on Fly.io, focusing on the following key concepts:

blueprints/observability-for-user-apps.html.md

@@ -5,6 +5,10 @@ nav: guides
 date: 2025-05-26
 ---
 
+<figure>
+  <img src="/static/images/observability.png" alt="Illustration by Annie Ruygt of a printed photo depicting a bird and a ghost backpacking through a forest" class="w-full max-w-lg mx-auto">
+</figure>
+
 When you run a platform for users to execute their own code on Fly.io—[think per-user development environments](/docs/blueprints/per-user-dev-environments/) or AI/LLM apps—it's a good idea to have real-time observability for those user apps. You might _also_ want to stream logs from those apps back to the original developer (your end-user), so they can see what their code is doing.
 
 Fly.io offers built-in telemetry based on [**NATS**](https://nats.io/) that you can tap into to achieve this. At a high level, Fly.io captures everything your app writes to stdout and funnels it into an internal NATS log stream. A proxy in front of this NATS cluster ensures that each organization can only access its own applications' logs. Both the `flyctl logs` command and the our web dashboard's "Live Logs" use this pipeline under the hood. We can use the same system! By connecting a NATS client within your Fly organization's [private network](/docs/networking/private-networking/), we can subscribe to log subjects and stream logs out to wherever we need, in real-time.

blueprints/opensshd.html.md

@@ -9,6 +9,10 @@ date: 2024-01-14
 redirect_from: /docs/app-guides/opensshd/
 ---
 
+<figure>
+  <img src="/static/images/openssh.png" alt="Illustration by Annie Ruygt of a terminal window, a computer and some numbers" class="w-full max-w-lg mx-auto">
+</figure>
+
 A number of tools allow you to interact with your server over SSH. These tools are useful for tasks such as
 copying files ([rsync](https://rsync.samba.org/+external), [scp](https://en.wikipedia.org/wiki/Secure_copy_protocol+external), [sshfs](https://github.com/libfuse/sshfs#sshfs+external)), 
 editing ([emacs](https://www.gnu.org/software/emacs/manual/html_node/emacs/Remote-Files.html+external), [vim](https://www.vim.org/scripts/script.php?script_id=1075+external), [vscode](https://code.visualstudio.com/docs/remote/ssh+external)), and

blueprints/supercronic.html.md

@@ -11,6 +11,10 @@ redirect_from:
   - /docs/app-guides/supercronic/
 ---
 
+<figure>
+  <img src="/static/images/supercronic.png" alt="Illustration by Annie Ruygt of Framkie the balloon wearing a sash and a prize ribbon in a gymnasium hall while a bird looks with admiration" class="w-full max-w-lg mx-auto">
+</figure>
+
 `crontab` is a little too opinionated for containers—it's a great little tool, but when run inside of containers it doesn't grab `ENV` vars how we'd like it to. Fortunately there's a Go binary called `supercronic` that's a drop-in replacement for containers.
 
 The good news is that it's pretty easy to get it running on Fly with a little bit of copy and pasting. Let's get to it.

blueprints/using-the-fly-docker-registry.html.md

@@ -4,6 +4,10 @@ layout: docs
 nav: guides
 ---
 
+<figure>
+  <img src="/static/images/using-the-fly-docker-reg.png" alt="Illustration by Annie Ruygt of Frankie the balloon and the Docker whale playing a game of bean bag toss" class="w-full max-w-lg mx-auto">
+</figure>
+
 Fly.io lets you deploy Docker containers as lightweight Firecracker VMs, running globally. While `fly launch` supports many frameworks and auto-generates deployment configurations, you can also build and push your own Docker images to Fly.io’s private registry and deploy them manually.
 
 This guide walks through building, pushing, deploying, and managing images via Fly.io’s Docker registry.

blueprints/volume-forking.html.md

@@ -6,6 +6,10 @@ author: kcmartin
 date: 2025-09-12
 ---
 
+<figure>
+  <img src="/static/images/volume-forking.png" alt="Illustration by Annie Ruygt of a blimp and a Fly rocket flying side by side" class="w-full max-w-lg mx-auto">
+</figure>
+
 <div class="callout">
 **This guide shows how to preload large files onto volumes using forking to improve startup performance. This is especially useful for apps with big model files, binaries, or databases.**
 </div>