Skip to main content
This guide covers updating a Dograh stack you’ve already deployed with Docker or a custom domain. You run commands from the same directory that contains your docker-compose.yaml (this is the dograh/ directory if you used setup_remote.sh).

​
Find an image version

Dograh publishes two images — dograh-api and dograh-ui — to both container registries: Each release is published under two kinds of tags:
Tag styleExampleWhen to use
Release tagv0.8.2Stable, recommended for production
Git commit SHAa1b2c3dBleeding edge — any commit merged to main
latestlatestTracks the most recent release tag
Always update dograh-api and dograh-ui to the same tag. The two images are built from the same commit and the UI expects API responses in a matching shape — mixing versions will break the app.

​
Option A: Update to the latest release

If your docker-compose.yaml uses :latest (the default), just pull and restart: 
docker compose down
docker compose up --pull always
--pull always forces Docker to fetch the latest :latest from the registry instead of reusing your cached image.

​
Option B: Pin a specific tag

To update (or roll back) to a specific release or commit, edit docker-compose.yaml and change the image: lines for both api and ui services to the same tag. Open the file: 
nano docker-compose.yaml
Find these two lines: 
  api:
    image: ${REGISTRY:-dograhai}/dograh-api:latest
  ui:
    image: ${REGISTRY:-dograhai}/dograh-ui:latest
Replace :latest with your chosen tag on both services — for example: 
  api:
    image: ${REGISTRY:-dograhai}/dograh-api:v0.8.2
  ui:
    image: ${REGISTRY:-dograhai}/dograh-ui:v0.8.2
You can use either registry. Leave REGISTRY unset for Docker Hub (dograhai), or export REGISTRY=ghcr.io/dograh-hq to pull from GitHub Container Registry.
Then bring the stack down and back up: 
docker compose down
docker compose up --pull always

​
Verify the update

Check the running image tags: 
docker compose ps --format "table {{.Service}}\t{{.Image}}"
You should see the API and UI both running the tag you pinned. Hit the health endpoint to confirm the API is responding: 
curl http://localhost:8000/api/v1/health

​
Roll back

If something breaks, roll back by pinning the previous tag using the same process in Option B and restarting. Your Postgres data volume persists across down/up cycles, so agents and call history are preserved.
Rolling back across a database migration is not always safe — if the newer release ran a schema migration, downgrading may leave the DB in a state the older API doesn’t understand. If in doubt, open an issue before rolling back.