dokploy-best-practiceslisted

# Dokploy Best Practices Apply these rules when deploying or reviewing applications, databases, Docker Compose stacks, domains, or infrastructure managed by Dokploy. Dokploy is a self-hostable PaaS that orchestrates **Docker Swarm** behind a **Traefik** reverse proxy, with a **PostgreSQL** + **Redis** control plane and a Next.js UI. Most behaviors (zero downtime, rollbacks, domains) are thin wrappers over Swarm and Traefik primitives — understanding both explains most pitfalls. ## Core mental model - A **Service** is one app/database/compose stack. Services live in an `Organization → Project → Environment → Service` hierarchy. Use Environments (`production`, `staging`) for isolation; never mix prod and staging in one environment. - **Variables cascade**: project → environment → service, each level overriding the last. Put shared secrets at project level, stage-specific values at environment level. Reference with `${{project.VAR}}`, `${{environment.VAR}}`, `${{VAR}}`. - **Applications** route via Traefik **file provider** (hot-reload, no redeploy for domain changes). **Docker Compose / templates** route via Traefik **labels** (redeploy required for any domain change). This single distinction explains most "domain not working" 404s. ## Golden rules 1. **Never build on the production server for real workloads.** Nixpacks/Buildpack builds are RAM/CPU heavy and can freeze the server. Build + push images in CI/CD (or a dedicated build server) and deploy by i