diff --git a/docs/network/allow-caddy-to-apps.md b/docs/network/allow-caddy-to-apps.md
index cdecaaf..0cd871a 100644
--- a/docs/network/allow-caddy-to-apps.md
+++ b/docs/network/allow-caddy-to-apps.md
@@ -122,6 +122,41 @@ Every policy in this table uses:
 
 ---
 
+## 3a. IoT → CADDY Policies (reverse direction)
+
+The Home Assistant host itself also needs to reach Caddy directly — it
+pulls `homelab-blueprint` from Forgejo (`git.home.brianpooe.com`, proxied
+through Caddy) to deploy its own docker-compose stack.
+
+**Two independent layers enforce traffic into the Caddy host — both must
+allow it, and both were found misconfigured while wiring this up:**
+
+1. **UniFi zone-based firewall** (router-level, VLAN → VLAN):
+
+   | Policy name | Source zone | Source IP | Src. Port | Destination zone | Destination IP | Destination port(s) | Purpose |
+   |---|---|---|---|---|---|---|---|
+   | `Allow HA to Caddy` | `IoT` | `10.0.30.6` (Home Assistant IP) | `Any` | `CADDY` | `10.0.15.5` (Caddy IP) | `443` | git fetch/pull of homelab-blueprint from Forgejo |
+
+   Src. Port must be `Any`, not restricted to HA's own listening ports
+   (8080/8123) — this is outbound traffic *from* HA, so the source port is
+   a random ephemeral port, not the port HA listens on. Setting Src. Port
+   to a "Home Assistant" port object here was the original bug: the rule
+   never matched, so traffic fell through to `Block All Traffic` below it.
+
+2. **`ufw` on the Caddy host itself** (10.0.15.5) — a second, separate
+   enforcement point the UniFi rule doesn't touch. It allow-lists inbound
+   80/443 per source subnet and did not include the IoT VLAN
+   (`10.0.30.0/24`):
+
+   ```bash
+   sudo ufw allow from 10.0.30.0/24 to any port 80,443 proto tcp
+   ```
+
+   `ufw status` on that host is the fastest way to check which subnets can
+   already reach it before assuming a UniFi rule is the problem.
+
+---
+
 ## 4. Public DNS Block Policies (per zone)
 
 Without these, devices can bypass Technitium by querying public resolvers