The CI/CD GitHub Workflows
The pipeline is implemented as a set of GitHub Actions workflows in .github/workflows/. Where Deploying with the CI/CD Pipeline covers the flow, this article covers the files — what each one is for. (The authoritative, current set is the .github/workflows/ directory itself, alongside 013_core_ci_cd_plugin_strategy.md; treat this as the role map.)
Checks before merge
ci-staging.yml— runs the check suite on pull requests targetingstaging: lint, type-check, and the unit / API / integration tests. It gates the PR, so the staging deploy can trust it rather than re-running checks.ci-production.yml— runs on PRs targetingmain, with the same checks plus version validation (theversion-checkthat enforces a proper version bump and release-notes discipline — see Versioning & Cutting a Release).
The rule of thumb: checks run before merge; deploy and release run after. There's no redundant re-checking after merge.
Build
build-docker-images.yml— builds the API and frontend Docker images and pushes them to GHCR (ghcr.io/{org}/{repo}-apiand-frontend). This is the workflow whose GHCR login and image tags you edit when forking (see Forking Circus).
Deploy
deploy-staging.yml— triggered by a merge tostaging: builds/pushesstaging-latestimages, SCPs the deploy files, runs migrations, brings services up, and (re)starts Caddy.deploy-production.yml— triggered by a merge tomain: the same sequence with versioned images, and it also creates a GitHub Release from.release_notes/{VERSION}.mdwhen the version is new.
Reading them for real
These are the workflows you'll interact with most; the directory may hold additional supporting workflows (release automation, housekeeping). When you need the exact, current behaviour — triggers, steps, image tags — read the files in .github/workflows/ directly, and 013 for the plugin/migration strategy they encode. When you fork, the files to update for your org and registry are called out in the deployment guide.