Procedures for initial setup, verifying health, upgrading and rolling back, and Boost-specific configuration pointers. For architecture and environment tables, see deployment-overview.md.
- Docker and Docker Compose v2 on the host.
- Directory layout: Git repo
weblate-docker(this tree) must live asweblate-docker/under the root of theweblateapplication checkout sodocker-compose.ymlcan usebuild.context: ..anddockerfile: weblate-docker/Dockerfile. The parent folder’s name is arbitrary (for exampleboost-weblatelocally or/opt/boost-weblateon the deployment server). See deployment-overview.md and theweblaterepo’s.github/workflows/cd.ymlfor an automated deploy sequence. Initialize the submodule or reproduce the same tree manually. - PostgreSQL reachable from the Weblate container. The sample
environment.exampleusesPOSTGRES_HOST=host.docker.internalfor a database on the host; adjust for your network (same Docker network as apostgresservice, cloud RDS, etc.). - Resources: Follow upstream production guidance for sizing; migrations may take several minutes on first start (
HEALTHCHECKstart period is five minutes inDockerfile).
-
From the
weblateapplication root (example pathboost-weblate/), ensureweblate-docker/is populated (submodule or clone). -
Recommended when mirroring production CI: from that same application root, copy the Docker ignore file into the build context (see
weblate.github/workflows/cd.yml):cp weblate-docker/.dockerignore .dockerignore
-
Change into this directory:
cd weblate-docker -
Create local env file:
cp environment.example environment
-
Edit
environment(do not commit). At minimum set PostgreSQL variables (POSTGRES_*),WEBLATE_ADMIN_PASSWORD(orWEBLATE_ADMIN_PASSWORD_FILE), and secrets required for your deployment. See Weblate generic Docker settings. -
Build and start:
docker compose build docker compose up -d
-
Port mapping: Default Compose publishes 8000 on the host → 8080 in the container. Browse
http://localhost:8000/(or your host) and sign in with the admin user configured viaWEBLATE_ADMIN_EMAIL/WEBLATE_ADMIN_PASSWORD. -
Optional sanity check inside the stack:
docker compose exec weblate weblate check --deployResolve reported issues before relying on the instance in production.
If you use the workflow_dispatch CD workflow in the weblate repo (.github/workflows/cd.yml), the remote script effectively runs:
cd /opt/boost-weblate
git pull origin develop
git submodule update --init weblate-docker
cp weblate-docker/.dockerignore .dockerignore
cd weblate-docker
docker compose down
docker compose up -d --buildAfter the containers restart, that workflow waits five minutes then verifies http://localhost:8000/healthz/ from the host (same port mapping as Initial setup). Align branch names (develop) and paths with your fork if they differ.
The image defines a HEALTHCHECK that runs health_check. It:
- HTTP: If the web stack is enabled, requests
/healthz/— eitherhttp://localhost:8080/healthz/orhttps://localhost:4443/healthz/when TLS certs exist under/app/data/ssl/. - Supervisor: Runs
supervisorctl status. Exit code 3 is treated as success (expected when one-shot services differ); other failures fail the check. - Processes: Fails if any supervised program is not in the expected running/stopped state (see script comments for
check).
Inspect status:
docker compose ps
docker inspect --format='{{.State.Health.Status}}' <weblate_container_id>Probe the same path your users reach, for example:
http://<host>:8000/healthz/with default port mapping, orhttps://<your-domain>/healthz/behind a reverse proxy.
Use timeouts consistent with your SLA; the script uses curl --max-time 30 for the internal check.
-
Read Weblate upgrade notes and your release’s changelog.
-
Back up the database (and optional file backup for
/app/data) per Weblate backup. -
Check out updated
weblateandweblate-dockerrevisions (matching tags or branches your team uses). -
Rebuild and recreate:
cd weblate-docker docker compose build --no-cache # optional, when you need a clean dependency layer docker compose up -d
The entrypoint runs migrations as part of startup; allow time for the health check to pass after deploy.
-
Verify
/healthz/, application login, and background tasks (Celery) if you use them heavily.
Weblate upgrades apply forward-only Django migrations. Rolling back only the container to an older image while the database has already migrated forward can fail or corrupt data.
Safer rollback pattern
- Redeploy the previous image you used before the failed release (tag or digest recorded in your environment table).
- If database migrations ran during the failed deploy, restore PostgreSQL from the backup taken immediately before that upgrade, then start the old image against that restored database.
If you did not take a backup before upgrading, treat rollback as high risk; prefer fixing forward or restoring from the last known-good backup.
Operational steps:
cd weblate-docker
# Example: use a previously tagged image (adjust tag to your registry workflow)
docker compose pull weblate # if using a registry tag
docker compose up -d weblateConfirm docker compose ps and /healthz/ before declaring the rollback complete.
Fork-only environment variables (OpenRouter batch translation, Boost endpoint timing, etc.) are documented in the Boost Weblate additions chapter in the weblate repo: docs/admin/boost-weblate.rst. Cross-check environment.example for variables such as OPENROUTER_API_KEY, OPENROUTER_MODEL, AUTO_BATCH_TRANSLATE_VIA_OPENROUTER, and BOOST_ENDPOINT_ADD_TRANSLATION_SECONDS.