Storage and Redis
Connect Postgres, Redis, object storage, and signed image delivery.
The production stack stores CMS and authentication data in Postgres, files in object storage, and operational state in Redis. The Image service reads originals and stores generated results in the same object bucket.
Access
You need deployment-secret, container-network, and volume administration.
State and consumers
| Service | Production behavior |
|---|---|
| Postgres | Stores authoritative CMS and authentication state in pgdata |
| Redis | Uses authentication and AOF in redis_data; persists queues, delayed jobs, and delivery cache |
| Object storage | Stores originals and generated images in minio_data; bucket objects are anonymously downloadable |
| Core API | Uploads through the public S3_PUBLIC_URL endpoint and queues file processing |
| Worker | Uses the public object endpoint and Redis jobs to complete file metadata processing |
| Image service | Loads objects over the internal network and stores generated results under _imagor |
Core API and Worker containers must resolve and reach S3_PUBLIC_URL. Test that hairpin or split-DNS path, not only browser access. The Image service uses the internal object endpoint instead.
Object setup attempts to create the bucket and anonymous-download policy, but its script can still exit 0 after a failed setup command and no application waits for it. Inspect the setup logs, then make an unauthenticated GET request for a non-sensitive test object before upload or image tests.
Check the services
docker compose -f docker-compose.prod.yaml ps -a
docker compose -f docker-compose.prod.yaml logs --tail=200Redact credentials, signed URLs, cookies, personal data, and content before sharing logs. Compose status should show Postgres healthy, Redis healthy through its authenticated PONG check, and object setup exited 0.
Use a non-sensitive test image to verify the full path:
- Upload it through the Admin app.
- Wait for Worker-generated metadata to appear.
- Load its public original URL without credentials; anonymous download is expected.
- Request one named signed image transform and confirm the generated result loads.
- Inspect Worker and Image service logs if any stage fails.
A green database or Redis health check does not prove uploads or image transforms work.
Change and recovery limits
Changing bucket names or object credentials requires a tested, coordinated update of object storage, setup, Core API, Worker, and Image service. Changing the image signing secret requires Core API, Delivery API, and Image service to move together; reverting all three restores validation of older URLs.
Never delete named volumes to fix a credential or bucket mismatch. Redis loss can remove delayed or queued work even when content survives. Pub/Sub invalidation messages are transient and are lost across a Redis interruption or restore. Object credential rotation, AOF recovery, queue replay, public-endpoint hairpin routing, and coordinated original/generated-object restore have not been drilled by the project.