Goal

Even though the scripts/deploy.sh is safe, we still need to protect from the risk of accidental misuse by people who don't read the docs.

Why it's safe here

• No hardcoded secrets. The script doesn't contain SSH keys, passwords, tokens, hosts, or credentials. It relies on .env, compose.override.yml (gitignored), and runtime context.
• Actual deployment requires access. Forks/cloners can't deploy to your servers without:
  1. SSH access to your host
  2. The GitHub Secrets (DEPLOY_SSH_HOST, DEPLOY_SSH_USER, DEPLOY_SSH_KEY, DEPLOY_PATH)
  3. The server's .env and compose.override.yml
  4. Docker permissions. The CI workflow in .github/workflows/deploy.yml is the only automated path that has those secrets.
• Destructive actions are gated by environment. docker compose down -v wipes volumes/containers; running it locally by accident is bad, but someone else running it against your servers is impossible without credentials. The script also checks for .env and exits if missing.
• Sensitive files are gitignored. .env, /compose.override.yml, docker/nginx/ssl/, etc. are excluded per .gitignore. The script explicitly moves/restores compose.override.yml to avoid pulling conflicts.

Potential concerns

• Information disclosure. Anyone can see your deployment topology (paths, commands, Docker setup, how assets are built/copied). This is common for open-source projects and usually not a major security issue on its own.
• Footgun for users. If someone clones and runs bash scripts/deploy.sh locally on their machine, it will pull from origin main, stop their containers with down -v, rebuild, etc. The script doesn't have a "dry run" or confirmation prompt. This could cause data loss if misused.
• Reliance on environment assumptions. The script assumes it's run in the repo root on the target server with Docker installed and the right permissions (it does git pull origin main and uses docker compose).

Recommendations

1. Add guardrails (optional but nice): check for a marker/env var (e.g., DEPLOY_ENV=production) or prompt for confirmation before destructive actions. Or document that it's server-only.
2. Rotate if ever exposed. If you ever accidentally commit secrets, rotate them immediately (SSH keys, API keys, etc.). Nothing like that is present now.
3. Consider moving to CI-only execution. Since CI already does the pull/assets upload/SSH orchestration, the script is mainly the server-side steps. That's reasonable.