Verify Service Containers
The production template contains five Beskid application images, Authentik, two PostgreSQL services, the private registry, and Watchtower. Public origins use standard HTTPS through the shared host edge.
Prerequisites
Section titled “Prerequisites”Use a supported container engine and the pinned Compose contract. Obtain the exact Woodpecker source SHA and matching immutable image tags without changing them.
Actions
Section titled “Actions”- Render the configuration with
docker compose --env-file .env.example configfrombeskid_sites/deploy. - Confirm every application image uses
cr.beskid-lang.org/beskid/*:productionand has a matching immutablesha-*audit tag. - Confirm that each service has all persistent volumes attached before it starts.
| Service | Container port | Persistent state |
|---|---|---|
| website | 80 | No service volume. |
| learn | 80 | No service volume in the pinned contract. |
| tracker | 3000 | tracker-data. |
| nexus | 8452 | nexus-data. |
| pckg | 8082 | pckg-packages; PostgreSQL uses its dedicated database volume. |
Expected result
Section titled “Expected result”Compose validation succeeds. Every required container is healthy, every Beskid application uses the controlled private-registry tag, and persistent volume boundaries match the production contract.
Recovery
Section titled “Recovery”If Compose validation fails, inspect the container logs, fix the lane input, and render it again. If a volume name differs from the recorded lane, stop and do not delete or recreate a persistent volume to make validation pass.
Next task
Section titled “Next task”Verify production delivery or hand off the verified container contract to the production operator.