Deployments

The website deploys from GitHub Actions. CI builds frontend assets, packages a release, uploads it over SSH, and flips a current symlink on the server.

The server does not build frontend assets and does not run Strapi migration commands during deploy.

Website Deploy Model

The reusable deploy workflow is .github/workflows/deploy.yml.

Environment-specific workflows call it:

• .github/workflows/deploy-staging.yml
• .github/workflows/deploy-production.yml

The deploy workflow:

1. Checks out the repository.
2. Installs pnpm dependencies with the committed lockfile.
3. Runs pnpm run build.
4. Creates a release artifact without .git, .github, .claude, .env, node_modules, vendor, or storage.
5. Uploads the artifact over SSH.
6. Runs scripts/deploy.sh on the server.

Release Layout

Each website environment uses this shape:

<DEPLOY_PATH>/
├── current -> releases/<release>
├── incoming/
├── releases/
└── shared/
    ├── .env
    ├── public-assets/
    ├── storage/
    └── users/

The web server document root points at:

<DEPLOY_PATH>/current/public

shared/.env, shared/storage/, shared/public-assets/, and shared/users/ survive release changes. Runtime Statamic CP user accounts live in shared/users/; role and group definitions remain versioned in Git.

Server-Side Deploy Steps

scripts/deploy.sh prepares the release and runs:

composer install --no-dev --optimize-autoloader --no-interaction --prefer-dist
php artisan optimize:clear
php artisan migrate --force
php artisan storage:link --force
php artisan statamic:stache:refresh
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan queue:restart

If DEPLOY_WARM_STATIC_CACHE is truthy, it also runs:

php please static:warm

The deploy script does not run frontend builds or Strapi migration commands on the server.

Required GitHub Environments

The application deploy uses two GitHub Environments:

• staging
• production

Required secrets:

• DEPLOY_HOST
• DEPLOY_PORT
• DEPLOY_USER
• DEPLOY_PATH
• DEPLOY_SSH_PRIVATE_KEY
• DEPLOY_KNOWN_HOSTS

Optional environment variables:

• DEPLOY_KEEP_RELEASES
• DEPLOY_WARM_STATIC_CACHE

Do not publish secret values, private server paths, or raw host fingerprints in the public docs.

Docs Site Deploy

The docs site has a separate workflow at .github/workflows/deploy-docs.yml. It builds Astro Starlight from docs/, packages docs/dist/, uploads static files over SSH, and flips the docs current symlink.

The docs workflow can run on pushes that affect:

• docs/**
• pnpm-lock.yaml
• pnpm-workspace.yaml
• .github/workflows/deploy-docs.yml

It can also be run manually from GitHub Actions.

Required docs environment secrets:

• DEPLOY_HOST
• DEPLOY_PORT
• DEPLOY_USER
• DEPLOY_DOCS_PATH
• DEPLOY_SSH_PRIVATE_KEY
• DEPLOY_KNOWN_HOSTS

The docs server layout is:

<DEPLOY_DOCS_PATH>/
├── current -> releases/<release>
├── incoming/
└── releases/

The docs.jglp.ch document root points at:

<DEPLOY_DOCS_PATH>/current

The docs vhost is static-only. It does not need PHP.

Rollback

Rollback is a symlink operation to a previous release. Use it when the current release is broken and a known-good release still exists under releases/.

High-level procedure:

1. Identify the previous known-good release directory.
2. Repoint current to that release.
3. Restart queue workers for the website.
4. Clear or warm caches if the rollback changes rendered content or compiled Laravel cache.
5. Record what was rolled back and why in the private incident notes.

Keep exact server commands and incident-specific details in code-docs/ or the incident record.