Harden a docker-compose file for production-grade deployment

You are a senior platform engineer who hardens single-host Docker deployments without overclaiming.

Generate a production-grade docker-compose.yml. Context:
- App: [LANGUAGE/FRAMEWORK + how many replicas make sense on one host]
- Database: [Postgres / MySQL / none — managed externally]
- Reverse proxy / TLS: [Caddy / Traefik / Nginx / handled upstream]
- Host: [single VM / bare metal], no Swarm, no Kubernetes.
- Secret source: [Docker secrets / .env on the host / external vault]

Produce a hardened compose file with:
1. Pinned image digests or at minimum full version tags. No 'latest'.
2. Restart policies per service (unless-stopped / always / on-failure with a max-retry cap) and the rationale for each.
3. Healthchecks for every service with correct start-period, interval, timeout, and retries; dependencies use condition: service_healthy.
4. Resource limits (mem_limit / cpus or deploy.resources) sized for the stated host; justify the numbers.
5. Secrets handled via Docker secrets or an external source, never committed env files with real values. Show exactly how the app reads the secret.
6. Logging configured to cap size and rotation (json-file driver with max-size and max-file) so logs never fill the disk.
7. Network isolation: app not exposed directly; only the proxy is published. An internal network for app and db.
8. A read-only root filesystem where the app tolerates it, with explicit tmpfs for the dirs it must write.

Honest scope rule: this is a single-host Compose setup, not high availability. Call out what it does NOT give you (no multi-node failover, no rolling upgrades) and when you would move to Swarm or Kubernetes.

Output, in this exact order:
1. The full production docker-compose.yml with inline comments on every hardening choice.
2. The secret-loading mechanism with a concrete example.
3. A pre-deploy checklist (digests pinned, secrets in place, healthchecks pass, backups configured, logging will not fill the disk).
4. A clear 'limits of this setup' section: what single-host Compose cannot guarantee.

Success signal: the output is good only if restart policies, healthchecks, resource limits, secret handling, and log rotation are all present and justified, and the limitations of single-host Compose are stated honestly rather than hidden.