diff --git a/setup.sh b/setup.sh
index 650cfdc..bdcb5f9 100755
--- a/setup.sh
+++ b/setup.sh
@@ -107,7 +107,24 @@ for d in config grafana grafana/provisioning kafka-data zk-data zk-log \
     $SUDO mkdir -p "$OBMP_DATA_ROOT/$d"
 done
 # Container processes run as assorted UIDs; lab-permissive perms.
-$SUDO chmod -R 777 "$OBMP_DATA_ROOT" 2>/dev/null || true
+# EXCEPT postgres/: postgres enforces its own perms and refuses to start if
+# its SSL key is group/world-accessible. A blanket 777 over an EXISTING data
+# tree makes psql_server.key 0777 -> FATAL on every re-deploy (fresh installs
+# are unaffected because the key is generated after this runs). Leave the
+# postgres tree alone; the image entrypoint owns it.
+for _p in "$OBMP_DATA_ROOT"/*; do
+    [ "$(basename "$_p")" = "postgres" ] && continue
+    $SUDO chmod -R 777 "$_p" 2>/dev/null || true
+done
+# Postgres bind dirs just need to exist and be reachable; the container
+# entrypoint chowns/chmods PGDATA itself on init.
+$SUDO chmod 777 "$OBMP_DATA_ROOT" "$OBMP_DATA_ROOT/postgres" 2>/dev/null || true
+# Repair the re-deploy damage if a previous setup.sh already clobbered an
+# initialized data dir: re-tighten the SSL key/cert so postgres will boot.
+if [ -f "$OBMP_DATA_ROOT/postgres/data/psql_server.key" ]; then
+    $SUDO chmod 600 "$OBMP_DATA_ROOT/postgres/data/psql_server.key" \
+                    "$OBMP_DATA_ROOT/postgres/data/psql_server.crt" 2>/dev/null || true
+fi
 
 # --- Grafana provisioning + dashboards --------------------------------------
 # Provisioning YAML points Grafana at /var/lib/grafana/dashboards/... (bind-