---
name: deploy-production
description: Deploy SHD.build main to production through Gitea Actions and verify the live application. Use for a production release or a failed production deployment.
---

# Deploy Production

Production deploys from `main` through `Validate and deploy production`. The workflow builds the candidate while the current app remains online, stops only the SHD app and scheduler, creates a database backup, migrates, then health-checks the replacement.

## Workflow

1. Confirm that the commit passed `npm run check` and `npm run build`, then push it to `main` through `git@git.jb.codes:jb/shd.build.git`.
2. Open the Gitea production workflow for that commit. Confirm `validate` and `deploy` both succeed.
3. Verify `https://shd.build/api/health`. Confirm `ready` is true and the database check reports `ok`.
4. When host access is required, use `ssh f302` and inspect `/opt/shd-build-production` with its `.env.deploy` and `compose.production.yml` files. Confirm the app is healthy and the scheduler is running.

## Migration Failure

1. Open the failed `Deploy production` log and identify the failing statement and target schema state.
2. Do not patch the production database by hand. Fix the idempotent migration in source, validate it locally, commit it, and push a new commit.
3. The next workflow deployment creates a new production backup before it retries the migration. Confirm the recovery deployment reaches a healthy app state.

## Guardrails

- Do not use `docker compose down --volumes` or delete production volumes.
- Do not run a second manual deployment while a Gitea deployment is active.
- Routine deployment preserves production data. Use `replace-production-database` only with explicit approval for a full clone.
- Report the commit SHA, workflow result, production health response, and backup path from any migration attempt.