Updating
Two things update, on purpose independently:
| Updates how | Who decides | |
|---|---|---|
| The desktop app | Automatically, on restart | Each person |
| The server stack | When you run an update | The administrator |
An app update never touches your server. That's deliberate: nobody's document server should restart because someone accepted an app update.
Before you update
Take a backup. Admin → Backups → Back up now. Thirty seconds, and it's the difference between a bad update and a lost afternoon.
The backend also protects itself: when an update changes the database schema, it dumps the database first and refuses to migrate if that dump fails.
Updating from the app
Admin → Updates shows the current version and whether a newer stack is available. Run update does the whole thing, streaming the log into the window: it fetches the current compose file, pulls the new images and restarts the stack.
Expect a few minutes and a large download. The app is unusable while the backend restarts; it reconnects on its own.
Automatically check for updates controls only whether you're told about new versions. Nothing installs itself.
Updating from a terminal
cd /opt/chronicler
docker compose pull
docker compose up -d
docker compose logs -f backend
pull fetches new images, up -d recreates the containers that changed. Your
volumes — database, documents, models — are untouched.
docker-compose.yml with the
current published one. Hand edits to that file (an offsite backup mount, a
pinned model) are lost. If you've customised it, update from the terminal
instead, or keep your customised copy and re-apply after each update.Pinning a version
latest means every update takes you to the newest release. On a server people
depend on, pin it:
CHRONICLER_VERSION=1.0.9
Then updating is a deliberate act: change the number, docker compose up -d.
Rolling back
Pin the previous version
CHRONICLER_VERSION=1.0.8
Bring it back up
docker compose up -d
Restore the backup if the schema changed
If the newer version migrated the database, an older backend may not read it. Restore the backup you took before updating (Backups and restore).
Updating Ollama
The model runtime has its own version:
OLLAMA_VERSION=0.32.4
Leave it alone unless you're chasing a specific fix. Downloaded models live in a separate volume and survive the change.
After an update
- Sign in and ask a question.
- Check Admin → Model still shows your model as active.
- Check Admin → Licensing still says Active.
- If search looks wrong, run Reindex all.
Update cadence
Roughly monthly is sensible for a working server: recent enough for fixes, not so eager that you're testing releases for everyone else. Read the release notes for anything mentioning migrations or breaking changes, and never update an hour before you need the thing.