# Docker Compose Change Review — Release Worksheet

Use this before merging a change to a Compose file. Fill it in from the **diff**,
not from memory. Pair it with a run of the free
[Docker Production Readiness Auditor](https://devopsaitoolkit.com/tools/docker-production-readiness-auditor/)
on both the old and new files so you can compare scores.

## 1. What changed
- [ ] I read the full diff (`git diff -- '*compose*.y*ml'`), not just the PR summary.
- [ ] Every added/changed image tag is **pinned** (no `latest`, no missing tag).
- [ ] No secret literal was added to `environment:` / `command:` / `args:`.
- [ ] No new host mount of `/var/run/docker.sock` or a sensitive host path.
- [ ] No new `privileged: true`, `cap_add`, `network_mode: host`, `pid: host`.
- [ ] No datastore/broker port newly published to `0.0.0.0`.

## 2. Reliability
- [ ] New/changed services have a `healthcheck`.
- [ ] `depends_on` uses `condition: service_healthy` where readiness matters.
- [ ] `restart:` policy is set.
- [ ] Resource limits (memory/CPU) are set for new services.

## 3. Blast radius
- [ ] Data-tier networks are still `internal: true`.
- [ ] Only the intended ports are published, and only on the intended interface.
- [ ] Volume changes won't drop or relocate persistent data.

## 4. Evidence
- Auditor score — before: ____  after: ____  (band: __________)
- New critical/high findings introduced by this change: ____________________
- Findings accepted as known risk (with reason): __________________________

## 5. Rollback
- [ ] I can restore the previous config quickly (previous tag + previous compose).
- [ ] Stateful changes (volumes, DB) have a tested restore path.

## Reminder
A static configuration review is **not** a runtime security test and **not** a
guarantee of application correctness. It catches configuration regressions before
they ship; it does not replace testing the change in a non-production environment.