diff --git a/nix/modules/hive-matrix.nix b/nix/modules/hive-matrix.nix
index b63cd224..875b165a 100644
--- a/nix/modules/hive-matrix.nix
+++ b/nix/modules/hive-matrix.nix
@@ -403,5 +403,22 @@ in
         cfg.httpPort
       ];
     };
+
+    # When the hive network module is on, the matrix container's resolver
+    # is the dnsmasq that runs in the gateway container (bound at
+    # `bridgeIp`). Order the matrix container start after the gateway
+    # container so the resolver is up before tuwunel's first federation
+    # lookups. tuwunel boots fine without this — it configures the resolver
+    # from `/etc/resolv.conf` at startup and only queries on-demand (the
+    # boot failure this module fixes was an *empty* resolv.conf, a parse
+    # error, not a connectivity one) — so this is robustness, not a boot
+    # requirement. Soft `after` ordering (not `requires`) keeps the matrix
+    # container's lifecycle decoupled from the gateway's. `network.enable`
+    # asserts `gateway.enable`, so the gateway container unit always exists
+    # here. (Declarative `containers.<n>` → `nixos-container@<n>.service`,
+    # per the hive-ci precedent.)
+    systemd.services."nixos-container@hive-matrix".after = lib.mkIf networkCfg.enable [
+      "nixos-container@hive-gateway.service"
+    ];
   };
 }