User Manual · 07 · Security & Compliance
WholeReach — Automated Marketing System

Security, Privacy & Compliance

Secrets handling, access control, data ownership, platform policy, disclosure law, backups, and disaster recovery.

← Contents ⬇ Download full PDF Glossary & Index

Secrets handling

  • Platform keys live in /opt/postiz/social.env, permission 600 (root-only), loaded into the app as environment variables.
  • Keys are installed by self-run scripts (set-*-keys.sh) — they never pass through chat, email, or an assistant.
  • Access tokens for connected accounts are stored in the hub database, not in code.
  • If a key is ever exposed, rotate it at the platform and re-run the installer.

Access control

  • Servers are reachable only by SSH key — no passwords.
  • Hub sign-up is disabled (DISABLE_REGISTRATION=true) now that the owner account exists, so no one can self-register.
  • Client approval links are HMAC-signed and expire — they can't be forged or reused indefinitely.
  • HTTPS everywhere via Let's Encrypt (certbot); the login cookie only works over HTTPS.

Data ownership & privacy

  • Each client's content and tokens are isolated to their tenant.
  • Public privacy & terms pages are published (required for Meta review), including a data-deletion path.
  • We store only what's needed to publish and report; we don't harvest audience data.
  • A client can be fully removed by deleting their tenant block, listings file, and connected accounts.

Compliance & platform policy

AreaWhat to know
FTC disclosurePaid or affiliate promotion must be disclosed. Keep endorsements truthful — the honesty guard helps, but disclosure is an editorial responsibility.
Platform TermsAutomated posting is allowed within each platform's API rules; avoid spammy volume. Our cadence is deliberately modest.
Email/CAN-SPAMIf you add newsletters, include a real unsubscribe and sender address.
Data protectionHandle any client/customer data on a need-to-use basis; honor deletion requests.

See the Resource Links page for the primary-source policy documents.

Backup & disaster recovery

  • Nightly backups run on the hub (backup.sh, 04:17 UTC), covering the database, the portal data, and config.
  • Backups are kept on a schedule and copied off-box (cloud object storage).
  • To rebuild the hub from scratch: provision a new server, restore the Docker stack and the portal directory, restore the database, re-point DNS. The connected-account tokens come back with the database restore.
  • The websites and source data on the main droplet have their own separate nightly backup.
Lesson learnedKeep the servers on manual OS updates so an unattended reboot never interrupts a run. Long jobs should survive a restart, not depend on the box never rebooting.

Incident response

  1. Contain — hit the kill switch.
  2. Diagnose — check the logs and the ntfy alerts (see Troubleshooting).
  3. Rotate — if credentials are involved, rotate keys and re-install.
  4. Resume — remove the PAUSE file once resolved.