apunkt/dograh
1
0
Fork 0
mirror of https://github.com/dograh-hq/dograh.git synced 2026-06-22 08:38:13 +02:00
Code Issues Projects Releases Packages Wiki Activity

feat(scripts): generate REDIS_PASSWORD on setup, plumb through compose (#458)

Browse source 
* feat(scripts): generate REDIS_PASSWORD on setup, plumb through compose

Per the discussion on #453, this takes the recommended path of extending
the setup scripts rather than introducing a parallel compose file.

  - scripts/setup_remote.sh now generates REDIS_PASSWORD alongside
    OSS_JWT_SECRET and POSTGRES_PASSWORD and writes it to the rendered
    .env (with a short comment noting it can be rotated, unlike the
    postgres password which is baked into the volume on first init).
  - scripts/start_docker.sh now generates REDIS_PASSWORD on first run
    if missing, mirroring the existing OSS_JWT_SECRET pattern (reuses
    generate_secret, which falls back through python3 → openssl →
    /dev/urandom).
  - docker-compose.yaml and docker-compose-local.yaml now interpolate
    ${REDIS_PASSWORD:-redissecret} in the redis --requirepass, the redis
    healthcheck, and the api REDIS_URL.

The :-redissecret fallback preserves backwards compatibility for users
with an existing .env that predates this change — they keep the old
value until they regenerate. New installs (via either script) get a
secure random hex.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* Harden local Docker secret setup

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: Abhishek Kumar <abhishek@a6k.me>
This commit is contained in:
Manuel Bruña 2026-06-21 04:41:31 -03:00 • committed by GitHub
parent ac91019d38
commit 17054e3f26
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
9 changed files with 99 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

3
docs/deployment/docker.mdx
View file

@ -56,7 +56,8 @@ Invoke-WebRequest -OutFile start_docker.ps1 https://raw.githubusercontent.com/do
This setup:
- Downloads the latest docker-compose.yaml
- Creates `OSS_JWT_SECRET` in `.env` if one does not already exist
- Creates `OSS_JWT_SECRET` and `REDIS_PASSWORD` in `.env` if they do not already exist
- Creates `POSTGRES_PASSWORD` for brand-new `.env` files; existing installs keep their original Postgres password
- Prompts before running Docker Compose
- Starts all required services including PostgreSQL, Redis, MinIO, API, and UI
- Pulls the latest images automatically

13
docs/deployment/update.mdx
View file

@ -18,13 +18,12 @@ Dograh publishes two images — `dograh-api` and `dograh-ui` — to both contain
- **GitHub Container Registry** — [github.com/orgs/dograh-hq/packages](https://github.com/orgs/dograh-hq/packages)
- **Docker Hub** — [hub.docker.com/u/dograhai](https://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.
Each release is published under release tags. Note the formats differ between GitHub releases and 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](https://github.com/dograh-hq/dograh/releases) |
| GitHub release tag | `dograh-vX.Y.Z` | `dograh-v1.28.0` | Use when copying the version from a GitHub release |
| 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 |
<Warning>
@ -49,7 +48,7 @@ curl -o update_remote.sh https://raw.githubusercontent.com/dograh-hq/dograh/main
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:
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` to refresh deployment files from the default branch — the script normalizes them. Non-interactive callers can set it via environment variable and skip the confirmation prompt:
```bash
TARGET_VERSION=1.28.0 DOGRAH_UPDATE_YES=1 bash update_remote.sh
@ -67,15 +66,17 @@ The script overwrites `docker-compose.yaml` and the remote helper bundle (`remot
## Local deployment
For local Docker installs (the [Quick Start](/deployment/docker#quick-start) flow or `setup_local.sh` / `setup_local.ps1`), there are no host-side config files to refresh — stop the stack, then use the startup script to preserve `OSS_JWT_SECRET` and pull new images:
For local Docker installs (the [Quick Start](/deployment/docker#quick-start) flow or `setup_local.sh` / `setup_local.ps1`), refresh `docker-compose.yaml` and the startup script, stop the stack, then run the startup script. The script preserves existing `.env` secrets, creates `REDIS_PASSWORD` if it is missing, and only creates `POSTGRES_PASSWORD` for brand-new `.env` files so existing Postgres volumes keep using their original password:
<CodeGroup>
```bash macOS/Linux
curl -o docker-compose.yaml https://raw.githubusercontent.com/dograh-hq/dograh/main/docker-compose.yaml
curl -o start_docker.sh https://raw.githubusercontent.com/dograh-hq/dograh/main/scripts/start_docker.sh && chmod +x start_docker.sh
docker compose down
./start_docker.sh
```
```powershell Windows
Invoke-WebRequest -OutFile docker-compose.yaml https://raw.githubusercontent.com/dograh-hq/dograh/main/docker-compose.yaml
Invoke-WebRequest -OutFile start_docker.ps1 https://raw.githubusercontent.com/dograh-hq/dograh/main/scripts/start_docker.ps1
docker compose down
.\start_docker.ps1
@ -144,6 +145,6 @@ 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.
</Warning>
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.
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`, `TURN_SECRET`, `POSTGRES_PASSWORD`, and `REDIS_PASSWORD` in `.env` unchanged across updates to preserve sessions, WebRTC auth, and service credentials.
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.