# Operations

## Routine commands

```bash
docker compose up --build -d
docker compose ps
docker compose logs -f proxy backend frontend postgres
docker compose down
```

Compose health checks all services. Through the virtual host, the public health endpoint
is `http://azionelab.org:8080/health/`; the aggregate content endpoint is
`http://azionelab.org:8080/api/site/home/`.

Test routing without changing the hosts file:

```bash
curl --resolve azionelab.org:8080:127.0.0.1 http://azionelab.org:8080/health/
```

Apply schema changes with `docker compose exec backend python manage.py migrate`.
Create editors with `createsuperuser`; use Wagtail permissions for later non-superuser
accounts.

The backend applies migrations at container startup. To permanently reset local
state, use `docker compose down --volumes`; this deletes both database and media.

## Backup and restore

Back up the database and media at the same logical point in time:

```bash
mkdir -p backups/media
docker compose stop frontend backend
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' > backups/database.sql
docker compose cp backend:/app/media/. backups/media/
docker compose start backend frontend
```

Restore is destructive: verify the backup in a disposable environment and take a fresh
backup first. Then stop both applications, recreate and restore the database, replace
the media content, restart, and verify health, API, admin login, and several images.
Keep real backups encrypted and off-host with a defined retention policy.

## Known risks

- Frontend fallback content can mask a CMS outage, so monitor backend health directly.
- Local named volumes are not off-host backups.
- Development media serving is unsuitable for production traffic.
- The local reverse proxy provides HTTP only; it does not manage certificates.