Upgrading and backups

Readsmith's deployment model keeps operations boring on purpose: every deploy is an immutable artifact, so upgrades and rollbacks are image swaps, and state worth backing up lives in exactly two places.

Upgrading

Pull the release
```
git pull --tags
```
Releases are tagged; the changelog says what each one changes.
Rebuild and restart
```
docker compose up -d --build
```
The image build recompiles your content against the new version. Database migrations run automatically on start.
Verify
Load the site, run one search, and spot-check /llms.txt.
Same content, new version. The old image remains available for rollback.

Rolling back

Builds are deterministic and bundles immutable, so rolling back is running the previous image again; there is no compiled state on the server to untangle. Keep the last known-good image tagged and a rollback is one docker compose up -d with that tag.

What to back up

What	Where	Why
The database	the `db-data` volume, or `pg_dump`	Search index, Ask AI records, jobs
Spec blobs	the `storage-data` volume	Persisted API-reference ingests
Your content	your repository	Already backed up if it is in git; the site rebuilds from it entirely

A nightly dumpbash

docker compose exec db pg_dump -U readsmith readsmith | gzip > backup-$(date +%F).sql.gz

The content repository plus these two stores reproduce the whole deployment. Nothing else on the host holds state.

Staying current

Watch releases on GitHub and read the changelog before upgrading. Patch releases are safe by default; anything requiring action says so at the top of its entry.