Document that LDAPS (636) shouldn't be port-forwarded to the internet

It's mapped to the host by default for LAN/VPN direct-LDAP clients
(ldap-client hosts, apps with their own LDAP auth settings), not for
exposure through a router/firewall -- LDAP simple-bind has no rate
limiting the way the HTTP login endpoints do. Recommend a VPN for
remote direct-LDAP clients instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/deployment.md

@@ -203,7 +203,15 @@ automates all four steps with `./setup.sh` — see
    container recreation.
 4. **Don't expose the UI's HTTP port to the internet** — terminate TLS at a
    front proxy and keep `3001` on the Docker network / localhost only.
-5. The all-in-one image runs slapd as the `ldap` user but the app as root
+5. **Don't port-forward LDAPS (636) to the internet either.** It's mapped to
+   the host by default for LAN/VPN clients that bind LDAP directly (other
+   hosts running `ldap-client`, apps with their own LDAP auth settings) — not
+   for exposure through your router/firewall. LDAP simple-bind is a
+   brute-force target and there's no rate limiting in front of it the way
+   there is for the HTTP login endpoints. If you need a remote host to bind
+   LDAP, put it behind a VPN (Tailscale, WireGuard, …) instead of forwarding
+   636 publicly.
+6. The all-in-one image runs slapd as the `ldap` user but the app as root
    (matches the bare-metal unit). Harden to a non-root user for production.
 
 [← Back to Home](index.html)