diff --git a/kubernetes/apps/otbr/deployment.yaml b/kubernetes/apps/otbr/deployment.yaml
index 2ebf0b84..7b867ba2 100644
--- a/kubernetes/apps/otbr/deployment.yaml
+++ b/kubernetes/apps/otbr/deployment.yaml
@@ -5,7 +5,26 @@ metadata:
   labels:
     app.kubernetes.io/name: otbr
 spec:
-  replicas: 1
+  # Disabled 2026-07-11 (replicas: 0) after otbr broke Matter.
+  #
+  # otbr is seeded with the Nest network's dataset so it should join the
+  # existing partition as an additive co-BR. In practice it does not merge
+  # cleanly: its SLZB-06 radio is RF-isolated enough from the Nest mesh that
+  # otbr elects itself leader of a rival partition (or the network re-addresses
+  # under a new OMR prefix, observed fd5f -> fdd5). The two same-network
+  # partitions then bridge only over the Ethernet backbone, which carries a
+  # ping but is too slow for the large fragmented CASE handshake -- every
+  # Matter device stays mDNS-discoverable while CASE times out. Removing otbr
+  # re-merges the mesh onto the Nest hubs and Matter recovers.
+  #
+  # This is NOT a diagnosis of a specific config bug: the DHCP/sbr routing
+  # changes (19a4482, df61407) were investigated and matter-server's IPv6 path
+  # to the mesh works (reaches devices, ping ok); sbr's v6 table 100 is an
+  # inert orphan and otbr's eth0 default is outranked by net1's pref-high RA
+  # default. The instability is at the Thread partition layer. Re-enable only
+  # after the co-BR integration is verified to MERGE (one partition, one OMR,
+  # otbr's router table shows the Nest routers) instead of split.
+  replicas: 0
   strategy:
     type: Recreate
   selector: