Update

Update your self-hosted Dograh stack to a newer image version

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).

There are three update flows depending on how you deployed:

• Remote, prebuilt mode (most users) — use update_remote.sh below.
• Local Docker — pull images and restart; see Local deployment.
• Remote, build mode (you have a docker-compose.override.yaml) — update via git; see Updating a source build.

Find an image version

Dograh publishes two images — dograh-api and dograh-ui — to both container registries:

• GitHub Container Registry — github.com/orgs/dograh-hq/packages
• Docker Hub — hub.docker.com/u/dograhai

Each release is published under two kinds of tags. Note the formats differ between GitHub releases and the Docker image tags — update_remote.sh understands both and normalizes for you.

Where	Tag format	Example	When to use
GitHub release tag	dograh-vX.Y.Z	dograh-v1.28.0	What you see at github.com/dograh-hq/dograh/releases
Docker image tag (semver)	X.Y.Z	1.28.0	Stable, recommended for production
Docker image tag (SHA)	short SHA	a1b2c3d	Bleeding edge — any commit merged to main
Docker image tag (latest)	latest	latest	Tracks 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. update_remote.sh handles this for you automatically.

Remote, prebuilt mode (recommended)

update_remote.sh is the supported path for updating a stack created with setup_remote.sh. In one shot it:

• Asks for a target version (defaults to the latest release tag on GitHub).
• Pulls docker-compose.yaml at that version and pins both api and ui images to it.
• Refreshes the remote helper bundle (remote_up.sh plus shared templates/helpers).
• Synchronizes the canonical remote keys in .env and validates the runtime config that dograh-init will render from it.
• Backs up every file it changes with a .bak.<timestamp> suffix.

From your install directory:

cd dograh
curl -o update_remote.sh https://raw.githubusercontent.com/dograh-hq/dograh/main/scripts/update_remote.sh
bash update_remote.sh

You’ll be prompted for the target version, defaulting to the most recent release. Accepted forms: bare semver (1.28.0), v-prefixed (v1.28.0), the full GitHub tag (dograh-v1.28.0), or main for bleeding edge — the script normalizes them. Non-interactive callers can set it via environment variable and skip the confirmation prompt:

TARGET_VERSION=1.28.0 DOGRAH_UPDATE_YES=1 bash update_remote.sh

After the script finishes, apply the update through the validated startup wrapper:

./remote_up.sh

The script overwrites docker-compose.yaml and the remote helper bundle (remote_up.sh, scripts/run_dograh_init.sh, scripts/lib/setup_common.sh, and deploy/templates/*) from the shared upstream deployment bundle. If you’ve made local edits to any of these, check the .bak.<timestamp> files after the update and re-apply your edits.

Local deployment

For local Docker installs (the Quick Start flow or setup_local.sh / setup_local.ps1), there are no host-side config files to refresh — pull new images and restart:

docker compose down
docker compose up --pull always

To pin a specific version instead of latest, edit docker-compose.yaml and change both image: lines for api and ui to the same tag (e.g. :1.28.0 — Docker image tags use bare semver, no v prefix), then run the commands above.

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 -k https://YOUR_SERVER_IP/api/v1/health      # remote
curl http://localhost:8000/api/v1/health           # local

Roll back

update_remote.sh saves backups of every file it touched. To roll back, restore them and recreate the stack — the exact commands (including the timestamp it used) are printed at the end of the script’s output. The generic form:

cd dograh
for f in docker-compose.yaml nginx.conf turnserver.conf .env remote_up.sh scripts/run_dograh_init.sh scripts/lib/setup_common.sh deploy/templates/nginx.remote.conf.template deploy/templates/turnserver.remote.conf.template; do
    [[ -f "$f.bak.<timestamp>" ]] && cp "$f.bak.<timestamp>" "$f"
done
./remote_up.sh

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.

Updating a source build

If you deployed in build mode (you’ll have a docker-compose.override.yaml in your install directory), update_remote.sh deliberately refuses to run — you already have the full repo locally and update via git:

cd dograh
git fetch

# Track latest main:
git pull
# Or pin to a specific release (git tag format is dograh-vX.Y.Z):
git checkout dograh-v1.28.0

# Pick up pipecat and other submodule bumps
git submodule update --init --recursive

# Rebuild and restart
sudo docker compose --profile remote build
sudo docker compose --profile remote up -d

If you update the pipecat submodule, you must run git submodule update --init --recursive before rebuilding, or the Docker build will not pick up pipecat changes.

If you maintain a fork with local customizations on top of upstream, merging conflicts in docker-compose.yaml, remote_up.sh, scripts/run_dograh_init.sh, deploy/templates/*, or setup_remote.sh is up to you — resolve them as you would any other git merge. Leave OSS_JWT_SECRET and TURN_SECRET in .env unchanged across updates to preserve sessions and WebRTC auth.

The same migration warning above applies: rolling back across a schema change can leave the DB in a state the older API can’t read.