Installing using Docker¶

With dockerized Weblate deployment you can get your personal Weblate instance up and running in seconds. All of Weblate’s dependencies are already included. PostgreSQL is set up as the default database and Valkey as a caching backend.

Hardware requirements¶

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):

3 GB of RAM
2 CPU cores
1 GB of storage space

Napomena

Actual requirements for your installation of Weblate vary heavily based on the size of the translations managed in it.

Memory usage¶

The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.

Savjet

For systems with less memory than recommended, Single-process Celery setup is recommended.

CPU usage¶

Many concurrent users increase the amount of needed CPU cores.

Weblate 2026.8 introduced NumPy as a required dependency. On x86-64 systems, the optimized NumPy build bundled in the Docker image requires an x86-64-v2 compatible CPU. Without the required CPU features, NumPy fails to load and Weblate cannot start.

Before upgrading, check for the required SSE4.2 CPU feature on the Linux system running Docker:

grep sse4_2 /proc/cpuinfo

Empty output indicates that a required CPU feature is unavailable. This is a preliminary check; finding SSE4.2 does not verify all x86-64-v2 CPU features.

If Docker runs in a virtual machine, run the check inside the guest. Virtual machines can hide CPU features supported by the host. Configure the virtual machine to expose the required host CPU features, then reboot the guest. If the physical CPU lacks the required features, upgrade the hardware.

Storage usage¶

The typical database storage usage is around 300 MB per 1 million hosted words.

Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.

Storage performance¶

Version control operations perform many filesystem metadata lookups. The vcs subdirectory in DATA_DIR therefore needs low read latency; storage with slow metadata access can make operations such as git status take a long time even when its bulk throughput is good. Keep CACHE_DIR on low-latency local or temporary storage when possible.

The deployment checks measure metadata lookup latency for both locations and warn when the median latency exceeds 10 milliseconds. This is an approximate point-in-time measurement affected by filesystem and system load. Rerun weblate check --deploy before changing the storage configuration.

Nodes¶

For small and medium-sized sites (millions of hosted words), all Weblate components (see Pregled arhitekture) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Database setup for Weblate).

Installation¶

Savjet

The following examples assume you have a working Docker environment, with docker-compose-plugin installed. Please check the Docker documentation for instructions.

This creates a Weblate deployment server via HTTP, so you should place it behind HTTPS terminating proxy. You can also deploy with a HTTPS proxy, see Automatic SSL certificates using Let’s Encrypt. For larger setups, please see Scaling horizontally.

Clone the weblate-docker repo:
```
git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker
```
Napomena

The Docker Compose files are example deployment configurations. Operators typically customize them for their own deployment and maintain those local changes. Weblate application updates are delivered through Docker image tags; there is no release-bound update path for customized Compose files.

Create a docker-compose.override.yml file with your settings. See Docker environment variables for full list of environment variables.

services:
  weblate:
    image: weblate/weblate:latest
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SERVER_EMAIL: weblate@example.com
      WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for the admin user
      WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
    ports:
    - 80:8080

Napomena

If WEBLATE_ADMIN_PASSWORD is not set, the admin user is created with a random password shown on first startup.

The provided example makes Weblate listen on port 80, edit the port mapping in the docker-compose.override.yml file to change it.

Start Weblate containers:
```
docker compose up
```

Enjoy your Weblate deployment, it’s accessible on port 80 of the weblate container.

Više informacija

Invoking management commands

Choosing Docker image registry¶

Weblate containers are published to following registries:

Docker Hub, see https://hub.docker.com/r/weblate/weblate
GitHub Packages registry, see https://github.com/WeblateOrg/docker/pkgs/container/weblate

Napomena

All examples currently fetch images from Docker Hub, please adjust the configuration accordingly to use a different registry.

Choosing Docker image tag¶

Please choose a tag that matches your environment and expectations:

Tag name	Opis	Use case
`latest`	Weblate stable release, matches latest tagged release	Rolling updates in a production environment
`<YEAR>`	Weblate stable release	Rolling updates within a calendar year in a production environment
`<YEAR>.<MONTH>`	Weblate stable release	Rolling updates within a monthly release in a production environment
`<YEAR>.<MONTH>.<PATCH>.<BUILD>`	Weblate stable release	Well defined deploy in a production environment
`edge`	Weblate stable release with development changes in the Docker container (for example updated dependencies)	Rolling updates in a staging environment
`edge-<DATE>-<SHA>`	Weblate stable release with development changes in the Docker container (for example updated dependencies)	Well defined deploy in a staging environment
`bleeding`	Development version Weblate from Git	Rolling updates to test upcoming Weblate features
`bleeding-<DATE>-<SHA>`	Development version Weblate from Git	Well defined deploy to test upcoming Weblate features

Every image is tested by our CI before it gets published, so even the bleeding version should be quite safe to use.

Full list of published tags can be found at GitHub Packages

Docker container with HTTPS support¶

Please see Installation for generic deployment instructions, this section only mentions differences compared to it.

SSL terminating proxy¶

SSL can be terminated outside Weblate container. To make this work well together, several headers need to be passed to the container so that it is aware of its actual environment. In more detail, these headers are described in Running behind reverse proxy.

Example nginx reverse proxy configuration for a Docker container.¶

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 3600s;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
}

Docker container environment for external SSL termination.¶

WEBLATE_ENABLE_HTTPS=1
WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR
WEBLATE_TRUSTED_PROXY_ADDRESSES=192.0.2.10

Replace the example trusted proxy address with the address or network of the reverse proxy as seen by the Weblate container. Make sure that untrusted clients cannot reach a published container port by bypassing the reverse proxy.

If the reverse proxy runs on the Docker host, you can give the host gateway a persistent name in docker-compose.override.yml and trust that name:

services:
  weblate:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      WEBLATE_TRUSTED_PROXY_ADDRESSES: host.docker.internal

Using own SSL certificates¶

In case you have own SSL certificate you want to use, simply place the files into the Weblate data volume (see Docker container volumes):

ssl/fullchain.pem containing the certificate including any needed CA certificates
ssl/privkey.pem containing the private key

Both of these files must be owned by the same user as the one starting the docker container and have file mask set to 600 (readable and writable only by the owning user).

Additionally, Weblate container will now accept SSL connections on port 4443, you will want to include the port forwarding for HTTPS in docker compose override:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

If you already host other sites on the same server, it is likely ports 80 and 443 are used by a reverse proxy, such as NGINX. To pass the HTTPS connection from NGINX to the docker container, you can use the following configuration:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <SITE_URL>;
    ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;

    location / {
            proxy_set_header HOST $host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
    }
}

Replace <SITE_URL>, <SITE> and <EXPOSED_DOCKER_PORT> with actual values from your environment.

Trusting custom CA certificates¶

Added in version 2026.11.

When Weblate connects to services secured by certificates issued by a private certificate authority (for example an internal SMTP, LDAP, or Git server), place the CA certificates into the Weblate data volume (see Docker container volumes):

ssl/ca-certificates/ containing one or more .crt files in PEM format

On every container start, the certificates are combined with the system CA bundle and made available to Python (requests), OpenSSL, libcurl, and Git via REQUESTS_CA_BUNDLE, SSL_CERT_FILE, CURL_CA_BUNDLE, and GIT_SSL_CAINFO. The system trust store is not modified, and removing a .crt file from the directory removes it from the bundle on the next start.

Napomena

Only files with the .crt extension are picked up.

Napomena

Weblate runs repository operations (clone, fetch, push) with a cleaned-up environment, but passes the CA certificate variables (SSL_CERT_FILE, SSL_CERT_DIR, GIT_SSL_CAINFO, GIT_SSL_CAPATH, REQUESTS_CA_BUNDLE and CURL_CA_BUNDLE) through to Git and other subprocesses, so HTTPS Git remotes trust the CA as well.

Automatic SSL certificates using Let’s Encrypt¶

In case you want to use Let’s Encrypt automatically generated SSL certificates on public installation, you need to add a reverse HTTPS proxy an additional Docker container, https-portal will be used for that. This is made use of in the docker-compose-https.yml file. Then create a docker-compose-https.override.yml file with your settings:

version: '3'
services:
  weblate:
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for admin user
  https-portal:
    environment:
      DOMAINS: 'weblate.example.com -> http://weblate:8080'

Whenever invoking docker compose you need to pass both files to it, and then do:

docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up

Upgrading the Docker container¶

Usually it is good idea to only update the Weblate container and keep the PostgreSQL container at the version you have, as upgrading PostgreSQL is quite painful and in most cases does not bring many benefits.

You can do this by sticking with the existing docker-compose and just pull the latest images and then restart:

# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f

The Weblate database should be automatically migrated on first startup, and there should be no need for additional manual actions.

Napomena

Direct upgrades are only supported for releases from the current or previous calendar year. If you need to upgrade from an older release, upgrade first to an intermediate version listed in Version-specific instructions.

If you use the example Compose files without local changes, you can also review updates in the docker-compose repository, though this is not needed for most Weblate upgrades. Customized Compose files need to be maintained as part of your deployment. See Upgrading PostgreSQL container for upgrading the PostgreSQL server.

Upgrading PostgreSQL container¶

Napomena

PostgreSQL 18 changed the default data directory inside the container. A common older setup mounted the database volume at /var/lib/postgresql/data, while PostgreSQL 18 now uses /var/lib/postgresql by default.

If you are upgrading from an older version, either update the mount target in your Docker configuration to the new path, or keep the old mount target and set PGDATA accordingly.

Leaving the old mount target unchanged without setting PGDATA can cause PostgreSQL to write its data outside the persisted volume.

See PGDATA documentation for more information.

PostgreSQL containers do not support automatic upgrading between version, you need to perform the upgrade manually. Following steps show one of the options of upgrading.

Više informacija

https://github.com/docker-library/postgres/issues/37

Zaustavi Weblate kontejner:
```
docker compose stop weblate cache
```

Backup the database:

docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql

Zaustavi spremnik baze podataka:
```
docker compose stop database
```
Ukloni postgreSQL jedinicu:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
Savjet

The volume name contains name of the Docker Compose project, which is by default the directory name what is weblate-docker in this documentation.
Adjust docker-compose.yml to use new PostgreSQL version.
Start the database container:
```
docker compose up -d database
```

Restore the database from the backup:

cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate

Savjet

Please check that the database name matches POSTGRES_DB.

(Optional) Update password for the Weblate user. This might be needed when migrating to PostgreSQL 14 or 15 as way of storing passwords has been changed:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
Savjet

Please check that the database name matches POSTGRES_DB.
Pokreni sve preostale spremnike:
```
docker compose up -d
```

Admin sign in¶

After container setup, you can sign in as admin user with password provided in WEBLATE_ADMIN_PASSWORD, or a random password generated on first start if that was not set.

To reset admin password, restart the container with WEBLATE_ADMIN_PASSWORD set to new password.

Više informacija

WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Number of processes and memory consumption¶

The number of worker processes for both the web application and Celery is determined automatically based on number of CPUs. This works well for most cloud virtual machines as these typically have few CPUs and good amount of memory.

By default, one combined Celery worker handles all task queues using a prefork pool with three times WEBLATE_WORKERS processes. Sharing the initial application memory between all Celery workers reduces memory usage while the higher process count increases task throughput.

In case you have a lot of CPU cores and hit out of memory issues, try reducing number of workers:

environment:
  WEBLATE_WORKERS: 2

You can fine-tune the combined worker:

environment:
  CELERY_COMBINED_OPTIONS: --concurrency 12 --prefetch-multiplier 1

Alternatively, use the split mode to run and fine-tune individual worker categories:

environment:
  CELERY_WORKER_MODE: split
  WEB_WORKERS: 4
  WEB_BLOCKING_THREADS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2 --prefetch-multiplier 1
  CELERY_NOTIFY_OPTIONS: --concurrency 1 --prefetch-multiplier 4
  CELERY_MEMORY_OPTIONS: --concurrency 1 --prefetch-multiplier 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1 --prefetch-multiplier 1
  CELERY_BACKUP_OPTIONS: --concurrency 1 --prefetch-multiplier 1

The prefetch multiplier controls how many tasks each worker execution slot can reserve. The default of one avoids reserving additional long-running or payload-heavy tasks. The notification worker uses four in this example because its short tasks can benefit from buffering. Increase the value only after measuring queue latency and worker memory usage.

Memory usage can be further reduced by running Celery in a single process:

environment:
  CELERY_WORKER_MODE: single

Više informacija

WEBLATE_WORKERS
CELERY_WORKER_MODE
CELERY_COMBINED_OPTIONS
CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS
CELERY_SINGLE_OPTIONS
WEBLATE_ASGI
WEB_WORKERS
WEB_BLOCKING_THREADS

Scaling horizontally¶

Added in version 4.6.

You can run multiple Weblate containers to scale the service horizontally. The /app/data volume has to be shared by all containers, it is recommended to use cluster filesystem such as GlusterFS for this. The /app/cache volume should be separate for each container.

Each Weblate container has defined role using WEBLATE_SERVICE environment variable. Please follow carefully the documentation as some of the services should be running just once in the cluster, and the order of the services matters as well.

You can find example setup in the docker-compose repo as docker-compose-split.yml.

Startup configuration warnings¶

The Docker container records actionable configuration warnings from startup in the shared /app/data volume. They are shown by weblate check --deploy and in the Izvještaj o preformansi management interface, in addition to being written to the container log.

Each container reports its warnings separately. This keeps warnings from containers with different WEBLATE_SERVICE roles visible in a horizontally scaled deployment. Reports are refreshed while their container is running and are removed during an orderly container shutdown. Reports left by an abrupt shutdown expire after five minutes, and stale report files are cleaned up automatically by later container startups.

Docker environment variables¶

Many of Weblate’s Konfiguracija can be set in the Docker container using the environment variables described below.

If you need to define a setting not exposed through Docker environment variables, see Configuration beyond environment variables.

Passing secrets¶

Added in version 5.0.

Weblate container supports passing secrets as files. To utilize that, append _FILE suffix to the environment variable and pass secret file via Docker.

Related docker-compose.yml might look like:

services:
   weblate:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password
   database:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password


secrets:
   db_password:
     file: db_password.txt

Više informacija

How to use secrets in Docker Compose

Generic settings¶

WEBLATE_DEBUG¶

Configures Django debug mode using DEBUG.

Primjer:

environment:
  WEBLATE_DEBUG: 1

Više informacija

Disable debug mode

WEBLATE_LOGLEVEL¶

Configures the logging verbosity. Set this to DEBUG to get more detailed logs.

Defaults to INFO when WEBLATE_DEBUG is turned off, DEBUG is used when debug mode is turned on.

For more silent logging use ERROR or WARNING.

WEBLATE_LOGLEVEL_DATABASE¶: Configures the logging of the database queries verbosity.

WEBLATE_LOG_GELF_HOST¶: Added in version 5.9.

Configures remote logging using GELF TCP connection. Can be used to integrate with Graylog.

WEBLATE_LOG_GELF_PORT¶: Added in version 5.9.

Use custom port for WEBLATE_LOG_GELF_HOST, defaults to 12201.

WEBLATE_SITE_TITLE¶: Changes the site-title shown in the header of all pages.

WEBLATE_SITE_DOMAIN¶

Configures the site domain. This parameter is required and accepts a hostname or IPv4 address.

Include a port between 1 and 65535 if using a non-standard one. IPv6 addresses are not currently supported.

Primjer:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Više informacija

WEBLATE_ADMIN_NAME¶

WEBLATE_ADMIN_EMAIL¶

Configures the site-admin’s name and e-mail. It is used for both ADMINS setting and creating admin user (see WEBLATE_ADMIN_PASSWORD for more info on that).

Primjer:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com

Više informacija

WEBLATE_ADMIN_PASSWORD¶

Sets the password for the admin user.

If not set and admin user does not exist, it is created with a random password shown on first container startup.
If not set and admin user exists, no action is performed.
If set the admin user is adjusted on every container startup to match WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME and WEBLATE_ADMIN_EMAIL.

Upozorenje

It might be a security risk to store password in the configuration file. Consider using this variable only for initial setup (or let Weblate generate random password on initial startup) or for password recovery.

Više informacija

Admin sign in
Passing secrets
WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_NOTIFY_ERROR¶

Whether to send e-mail to admins upon server error. Turned on by default.

You might want to use other error collection like Sentry or Rollbar and turn this off.

Više informacija

WEBLATE_SERVER_EMAIL¶

The email address that error messages are sent from.

Više informacija

WEBLATE_DEFAULT_FROM_EMAIL¶

Configures the address for outgoing e-mails.

Više informacija

WEBLATE_ADMINS_CONTACT¶: Configures ADMINS_CONTACT.

WEBLATE_USER_DIRECTORY_VISIBILITY¶: Controls user discovery: all (default), scoped, or disabled. Resource-scoped API searches and autocomplete remain available in both restricted modes. See USER_DIRECTORY_VISIBILITY.

WEBLATE_USER_PROFILE_VISIBILITY¶: Controls profile access: public (default), authenticated, or admins. Self access and administrative access remain available. This is independent of directory visibility. See USER_PROFILE_VISIBILITY.

WEBLATE_CONTACT_FORM¶: Configures contact form behavior, see CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS¶

Configures allowed HTTP hostnames using ALLOWED_HOSTS.

Defaults to * which allows all hostnames.

Primjer:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com

Više informacija

WEBLATE_REGISTRATION_OPEN¶

Configures whether registrations are open by toggling REGISTRATION_OPEN.

Primjer:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_CAPTCHA¶

Added in version 5.10.

Configures whether captcha is used for registration and other unauthenticated actions, see REGISTRATION_CAPTCHA.

Primjer:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

Configure which authentication methods can be used to create new account via REGISTRATION_ALLOW_BACKENDS.

Primjer:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2

WEBLATE_REGISTRATION_REBIND¶: Added in version 4.16.

Configures REGISTRATION_REBIND.

WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS¶

Added in version 5.16.1.

Configures REGISTRATION_ALLOW_DISPOSABLE_EMAILS.

Primjer:

environment:
  WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS: 1

WEBLATE_PROJECT_WEB_RESTRICT_PRIVATE¶

Added in version 5.17.

Configures PROJECT_WEB_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_PROJECT_WEB_RESTRICT_ALLOWLIST¶

Added in version 5.17.

Configures PROJECT_WEB_RESTRICT_ALLOWLIST.

Expects a comma-separated list of trusted project slugs.

WEBLATE_WEBHOOK_RESTRICT_PRIVATE¶

Added in version 5.17.

Configures WEBHOOK_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_WEBHOOK_PRIVATE_ALLOWLIST¶

Added in version 5.17.

Configures WEBHOOK_PRIVATE_ALLOWLIST.

Expects a comma-separated list of trusted hostnames or domains.

WEBLATE_ALLOWED_ASSET_SIZE¶: Added in version 2025.7.

Configures ALLOWED_ASSET_SIZE.

WEBLATE_ASSET_RESTRICT_PRIVATE¶

Added in version 2025.5.

Configures ASSET_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_ASSET_PRIVATE_ALLOWLIST¶

Added in version 2025.5.

Configures ASSET_PRIVATE_ALLOWLIST.

Expects a comma-separated list of trusted hostnames or domains.

WEBLATE_TIME_ZONE¶

Configures the used time zone in Weblate, see TIME_ZONE.

Napomena

To change the time zone of the Docker container itself, use the TZ environment variable.

Primjer:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS¶

Makes Weblate assume it is operated behind a reverse HTTPS proxy, it makes Weblate use HTTPS in e-mail and API links or set secure flags on cookies.

Savjet

Please see ENABLE_HTTPS documentation for possible caveats.

Napomena

This does not make the Weblate container accept HTTPS connections, you need to configure that as well, see Docker container with HTTPS support for examples.

Primjer:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Više informacija

WEBLATE_NGINX_IPV6¶

Added in version 5.17.

Controls whether the bundled NGINX listens on IPv6 addresses.

Podržane vrijednosti su:

auto to enable IPv6 listeners only when IPv6 is available in the container runtime. This is the default.
on to always enable IPv6 listeners.
off to disable IPv6 listeners.

Primjer:

environment:
  WEBLATE_NGINX_IPV6: auto

WEBLATE_IP_PROXY_HEADER¶

Lets Weblate fetch the IP address from any given HTTP header. Use this when using a reverse proxy in front of the Weblate container.

Enables IP_BEHIND_REVERSE_PROXY and sets IP_PROXY_HEADER.

When set to HTTP_X_FORWARDED_FOR, the bundled nginx resolves the client address using WEBLATE_TRUSTED_PROXY_ADDRESSES, uses that address in its logs, and forwards one normalized address to Weblate.

Promijenjeno u verziji 2026.9: The bundled nginx no longer trusts X-Forwarded-For from all network addresses. Trusted proxy addresses have to be configured explicitly.

Napomena

The format must conform to Django’s expectations. Django transforms raw HTTP header names as follows:

converts all characters to uppercase
replaces any hyphens with underscores
prepends HTTP_ prefix

So X-Forwarded-For would be mapped to HTTP_X_FORWARDED_FOR.

Primjer:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
  WEBLATE_TRUSTED_PROXY_ADDRESSES: "192.0.2.10 2001:db8::/64 proxy"

WEBLATE_TRUSTED_PROXY_ADDRESSES¶

Added in version 2026.9.

Configures the IPv4 or IPv6 addresses, networks, or hostnames of reverse proxies trusted by the bundled nginx to supply X-Forwarded-For. Separate multiple values by whitespace.

This setting is used only when WEBLATE_IP_PROXY_HEADER is HTTP_X_FORWARDED_FOR. If the list is empty, nginx uses the immediate TCP peer in its logs and forwards that address to Weblate.

Only list proxies under your control, and do not expose the Weblate container through a path which bypasses them.

Primjer:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
  WEBLATE_TRUSTED_PROXY_ADDRESSES: "192.0.2.10 2001:db8::/64 proxy"

WEBLATE_IP_PROXY_OFFSET¶

Added in version 5.0.1.

Configures IP_PROXY_OFFSET.

When WEBLATE_IP_PROXY_HEADER is HTTP_X_FORWARDED_FOR, the bundled nginx forwards one normalized address and the container uses an effective offset of 0.

WEBLATE_USE_X_FORWARDED_PORT¶: Added in version 5.0.1.

A boolean that specifies whether to use the X-Forwarded-Port header in preference to the SERVER_PORT META variable. This should only be enabled if a proxy which sets this header is in use.

Više informacija

USE_X_FORWARDED_PORT

Napomena

This is a boolean setting (use "true" or "false").

WEBLATE_SECURE_PROXY_SSL_HEADER¶

A tuple representing an HTTP header/value combination that signifies a request is secure. This is needed when Weblate is running behind a reverse proxy doing SSL termination which does not pass standard HTTPS headers.

Primjer:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Više informacija

WEBLATE_REQUIRE_LOGIN¶

Aktivira REQUIRE_LOGIN za provođenje autentifikacije na cijelom Weblateu.

Primjer:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LEGAL_INTEGRATION¶

Enables the Legal module module in Docker deployments. By default, the integration is disabled; leave this variable unset or empty to disable it.

Podržane vrijednosti su:

tos-confirm to enable the legal module and enforce legal document confirmation during social authentication and for signed-in users.
wllegal to enable the same integration and additionally load the hosted legal document templates from wllegal. These templates are used by services operated by Weblate s.r.o. and are not intended for general use.

To provide your own legal documents in Docker, override the templates in /app/data/python/customize/templates/legal/documents, see Replacing logo and other static files.

Recreate the Docker container after changing this environment variable, for example using docker compose up -d. Restarting an existing container does not apply changed environment values.

Primjer:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm

Više informacija

Legal module
Replacing logo and other static files

WEBLATE_LEGAL_DOCUMENT_CSS_CLASS¶

Configures LEGAL_DOCUMENT_CSS_CLASS in Docker deployments with WEBLATE_LEGAL_INTEGRATION enabled.

Set this to the class targeted by your custom legal stylesheet. Set it to an empty string to render legal documents without a wrapper class.

Primjer:

environment:
  WEBLATE_LEGAL_DOCUMENT_CSS_CLASS: ""

WEBLATE_LEGAL_HIDDEN_DOCUMENTS¶

Configures LEGAL_HIDDEN_DOCUMENTS in Docker deployments with WEBLATE_LEGAL_INTEGRATION enabled.

Provide a comma-separated list of legal document page identifiers.

External legal document URLs take priority over internal page links. The following configuration hides the internal pages, links both documents externally, and requires one agreement covering both:

Primjer:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm
  WEBLATE_LEGAL_HIDDEN_DOCUMENTS: terms,privacy
  WEBLATE_LEGAL_URL: https://example.com/terms/
  WEBLATE_PRIVACY_URL: https://example.com/privacy/

WEBLATE_PUBLIC_ENGAGE¶: Enables PUBLIC_ENGAGE.

WEBLATE_GOOGLE_ANALYTICS_ID¶: Configures ID for Google Analytics by changing GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE¶: Configures the default title and message for pull requests via API by changing DEFAULT_PULL_MESSAGE.

Više informacija

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES¶: Configures the language simplification policy, see SIMPLIFY_LANGUAGES.

WEBLATE_HIDE_SHARED_GLOSSARY_COMPONENTS¶: Hides glossary components when shared to other projects, see HIDE_SHARED_GLOSSARY_COMPONENTS.

WEBLATE_DEFAULT_ACCESS_CONTROL¶: Configures the default Kontrola pristupa for new projects, see DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_TRANSLATION_REVIEW¶: Added in version 5.16.

Configures the default value for Aktiviraj preglede, turned off by default.

WEBLATE_DEFAULT_SOURCE_REVIEW¶: Added in version 5.16.

Configures the default value for Aktiviraj preglede izvora, turned off by default.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: Configures the default value for Ograničen pristup for new components, see DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: Configures the default value for Dopusti dijeljenje prijevoda for new components, see DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL¶: Configures DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME¶: Configures DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM¶: Configures DEFAULT_SHARED_TM.

WEBLATE_DEFAULT_AUTOCLEAN_TM¶: Konfigurira DEFAULT_AUTOCLEAN_TM.

WEBLATE_COMMIT_PENDING_HOURS¶: Configures the default value for Starost promjena koje želiš spremiti for new components, see COMMIT_PENDING_HOURS.

WEBLATE_GPG_IDENTITY¶: Configures GPG signing of commits, see WEBLATE_GPG_IDENTITY.

Više informacija

Potpisivanje Git promjena s GnuPG-om

WEBLATE_URL_PREFIX¶: Configures URL prefix where Weblate is running, see URL_PREFIX. Leave it empty to serve Weblate at the root, or use slash-separated path segments starting with a slash, for example /translations or /tools/translations. Each segment can contain ASCII letters, digits, _, and -.

WEBLATE_STATIC_URL¶: Configures URL prefix for static files served from CACHE_DIR.

WEBLATE_SILENCED_SYSTEM_CHECKS¶: Configures checks which you do not want to be displayed, see SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC¶

WEBLATE_CSP_IMG_SRC¶

WEBLATE_CSP_CONNECT_SRC¶

WEBLATE_CSP_STYLE_SRC¶

WEBLATE_CSP_FONT_SRC¶

WEBLATE_CSP_FORM_SRC¶

Allows to customize Content-Security-Policy HTTP header.

Više informacija

WEBLATE_LICENSE_FILTER¶: Configures LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED¶: Configures LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED¶: Configures WEBSITE_REQUIRED.

WEBLATE_VERSION_DISPLAY¶: Configures VERSION_DISPLAY.

WEBLATE_HIDE_VERSION¶: Configures HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES¶: Configures BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH¶: Configures DEFAULT_AUTO_WATCH.

WEBLATE_DEFAULT_NOTIFICATIONS¶

Added in version 2026.10.1.

Configures DEFAULT_NOTIFICATIONS.

Primjer:

environment:
  WEBLATE_DEFAULT_NOTIFICATIONS: 0:1:MentionCommentNotificaton,10:1:LastAuthorCommentNotificaton

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶

WEBLATE_RATELIMIT_OCR_ATTEMPTS¶

WEBLATE_RATELIMIT_OCR_WINDOW¶

WEBLATE_RATELIMIT_OCR_LOCKOUT¶

Added in version 4.6.

Konfigurira ograničenje stope.

Savjet

You can set configuration for any rate limiter scopes. To do that add WEBLATE_ prefix to any of setting described in Rate limiting.

Više informacija

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

Configures API_RATELIMIT_ANON and API_RATELIMIT_USER. Defaults to 100/day for anonymous and 5000/hour for authenticated users.

Više informacija

API rate limiting

WEBLATE_API_RATELIMIT_USER_OVERRIDES¶

WEBLATE_API_RATELIMIT_IP_OVERRIDES¶

Added in version 2026.10.

JSON mappings configuring API_RATELIMIT_USER_OVERRIDES and API_RATELIMIT_IP_OVERRIDES. Both default to empty objects. Use JSON null to exempt a user, IP address, or network from API throttling.

For example, in compose.override.yaml:

services:
  weblate:
    environment:
      WEBLATE_API_RATELIMIT_USER_OVERRIDES: '{"automation":"20000/hour"}'
      WEBLATE_API_RATELIMIT_IP_OVERRIDES: '{"192.0.2.42":null,"198.51.100.0/24":"10000/hour"}'

Username rules take precedence over IP rules. See API rate limiting for counting behavior and proxy configuration requirements.

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

Configures ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

Configures ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

Configures AVATAR_URL_PREFIX.

WEBLATE_AVATAR_URL_TEMPLATE¶: Added in version 2026.10.

Configures AVATAR_URL_TEMPLATE.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

Configures LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

Configures SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

Configures BORG_EXTRA_ARGS as a comma separated list of args.

Primjer:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

Configures ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK¶: Added in version 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD¶: Added in version 4.15.

Configures EXTRA_HTML_HEAD.

WEBLATE_INTERNAL_BOT_EMAIL_TEMPLATE¶: Added in version 2026.7.1.

Configures INTERNAL_BOT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Added in version 4.15.

Configures PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Added in version 4.15.

Configures PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE¶: Added in version 5.16.

Configures PRIVATE_COMMIT_NAME_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN¶

Added in version 5.16.

Configures PRIVATE_COMMIT_NAME_OPT_IN.

To use private commit e-mails and names by default, set both opt-in variables to False in docker-compose.override.yml:

services:
  weblate:
    environment:
      WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN: "False"
      WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN: "False"
      WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE: "user-{user_id}@users.noreply.{site_domain}"
      WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE: "{site_title} user {user_id}"

The template variables are optional customizations. This e-mail template uses the user ID instead of the username included in the default template. Setting the templates alone leaves private commit identities opt-in.

These defaults apply to new and existing users without explicit commit identity choices. Users can still select their account identity. Existing commits are unchanged.

After changing the environment, run docker compose up -d to recreate the affected containers. Apply the same configuration to separately deployed workers so both web and worker processes use the new defaults.

WEBLATE_UNUSED_ALERT_DAYS¶: Added in version 4.17.

Configures UNUSED_ALERT_DAYS.

WEBLATE_REPORT_EXPIRY¶: Added in version 2026.8.

Configures REPORT_EXPIRY.

WEBLATE_UPDATE_LANGUAGES¶: Added in version 4.3.2.

Configures UPDATE_LANGUAGES.

WEBLATE_VCS_ALLOW_HOSTS¶: Added in version 5.15.

Konfigurira VCS_ALLOW_HOSTS.

WEBLATE_VCS_PRIVATE_ALLOWLIST¶: Added in version 2026.9.

Configures VCS_PRIVATE_ALLOWLIST.

WEBLATE_VCS_ALLOW_SCHEMES¶

Added in version 5.15.

Konfigurira VCS_ALLOW_SCHEMES.

The file scheme is disabled for security reasons. Including it prevents Weblate from starting.

WEBLATE_VCS_RESTRICT_PRIVATE¶: Added in version 5.17.

Configures VCS_RESTRICT_PRIVATE.

WEBLATE_VCS_CLONE_DEPTH¶: Added in version 5.4.

Konfigurira VCS_CLONE_DEPTH.

WEBLATE_VCS_API_DELAY¶: Added in version 5.4.

Konfigurira VCS_API_DELAY.

WEBLATE_VCS_API_TIMEOUT¶: Added in version 5.15.

Konfigurira VCS_API_TIMEOUT.

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

Allow CORS requests to API from given origins.

Primjer:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org

WEBLATE_CORS_ALLOW_ALL_ORIGINS¶: Added in version 5.6.1: Allows CORS requests to API from all origins.

WEBLATE_WEBSITE_ALERTS_ENABLED¶: Added in version 5.17.

Configures WEBSITE_ALERTS_ENABLED.

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

Configures maximal body size accepted by the built-in web server. Use a non-negative integer with an optional k, m, or g suffix. The suffix is case-insensitive, and 0 disables the request body size limit.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Savjet

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Automatic SSL certificates using Let’s Encrypt.

WEBLATE_TRANSLATION_UPLOAD_MAX_SIZE¶

Configures TRANSLATION_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_COMPONENT_ZIP_UPLOAD_MAX_SIZE¶

Configures COMPONENT_ZIP_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_UPLOAD_MAX_SIZE¶

Configures PROJECT_BACKUP_UPLOAD_MAX_SIZE.

The value is in bytes. Make sure CLIENT_MAX_BODY_SIZE is also large enough for uploaded backup files.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_MEMBERS¶: Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_MEMBERS.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE¶

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE¶

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE¶

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO¶: Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

Code-hosting sites credentials¶

In the Docker container, the code-hosting credentials can be configured either in separate variables or using a Python dictionary to set them at once. The following examples are for GitHub zahtjevi za preuzimanje, but apply to all Integracija kontrole verzija with appropriately changed variable names.

Važno

All environment variable names must include the WEBLATE_ prefix. For example, to configure GitHub credentials, use WEBLATE_GITHUB_USERNAME, not GITHUB_USERNAME. This applies whether you’re configuring for pull requests or any other VCS integration.

An example configuration for GitHub pull requests might look like:

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

Will be used as:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

Alternatively the Python dictionary can be provided as a string:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

Ili staza do datoteke koja sadrži Python rječnik:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

WEBLATE_GITHUB_USERNAME¶

WEBLATE_GITHUB_TOKEN¶

WEBLATE_GITHUB_HOST¶

WEBLATE_GITHUB_CREDENTIALS¶: Configures GitHub zahtjevi za preuzimanje by changing GITHUB_CREDENTIALS.

Više informacija

Configuring code-hosting credentials in Docker

WEBLATE_GITHUB_LEGACY_APP_WEBHOOK_SECRET¶: Added in version 2026.8.

Configures GITHUB_LEGACY_APP_WEBHOOK_SECRET. The _FILE variant can be used to load the secret from a file.

GitHub Apps registered through the in-app manifest flow are stored in the database and do not need environment variables. See GitHub notifications.

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Configures GitLab zahtjevi za sjedinjavanje by changing GITLAB_CREDENTIALS.

Više informacija

Configuring code-hosting credentials in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Configures Gitea zahtjevi za preuzimanje by changing GITEA_CREDENTIALS.

Više informacija

Configuring code-hosting credentials in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Configures Pagure zahtjevi za sjedinjavanje by changing PAGURE_CREDENTIALS.

Više informacija

Configuring code-hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Configures Bitbucket Data Center zahtjevi za preuzimanje by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME¶

WEBLATE_BITBUCKETCLOUD_WORKSPACE¶

WEBLATE_BITBUCKETCLOUD_TOKEN¶

WEBLATE_BITBUCKETCLOUD_HOST¶

WEBLATE_BITBUCKETCLOUD_CREDENTIALS¶: Configures Bitbucket Cloud zahtjevi za preuzimanje by changing BITBUCKETCLOUD_CREDENTIALS.

Više informacija

Configuring code-hosting credentials in Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: Configures Azure DevOps zahtjevi za preuzimanje by changing AZURE_DEVOPS_CREDENTIALS.

Više informacija

Configuring code-hosting credentials in Docker

Translation services settings¶

Promijenjeno u verziji 4.13: Translation services are now configured in the user interface, see Translation services.

The existing environment variables are imported during the migration to Weblate 4.13, but changing them will not have any further effect.

Postavke autentifikacije¶

Savjet

The e-mail based authentication is turned on unless disabled by WEBLATE_NO_EMAIL_AUTH.

LDAP¶

WEBLATE_AUTH_LDAP_SERVER_URI¶

WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶

WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶

WEBLATE_AUTH_LDAP_BIND_DN¶

WEBLATE_AUTH_LDAP_BIND_PASSWORD¶

WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS¶

WEBLATE_AUTH_LDAP_USER_SEARCH¶

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER¶

Konfiguracija LDAP autentifikacije.

Example for direct bind:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail

Example for search and bind:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com

Example for union search and bind:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com

Example with search and bind against Active Directory:

environment:
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)

Više informacija

GitHub¶

WEBLATE_SOCIAL_AUTH_GITHUB_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID¶: Enables GitHub autentifikacija.

GitHub Enterprise Edition¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶: Enables GitHub EE autentifikacija.

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶: Enables Bitbucket autentifikacija.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Enables Facebook OAuth 2.

Google¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS¶: Enables Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Enables GitLab OAuth 2.

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Aktivira Gitea autentifikaciju.

Microsoft Entra ID¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Enables Microsoft Entra ID authentication, see Microsoft Entra ID.

Microsoft Entra ID with Tenant support¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: Enables Microsoft Entra ID authentication with Tenant support, see Microsoft Entra ID.

Keycloak¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE¶: Enables Keycloak authentication, see Keycloak - Open Source Red Hat SSO.

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ID_KEY¶

Added in version 5.17.

Configures which claim is used as the unique user identifier from Keycloak. Defaults to email.

Savjet

When Keycloak is configured to abstract third-party IDP, you will need to configure WEBLATE_CSP_FORM_SRC for the third-party IDP domain.

Example when Keycloak is passing authentication to Microsoft.¶

environment:
  WEBLATE_CSP_FORM_SRC: login.microsoftonline.com

Dostavljači Linuxa¶

You can enable authentication using Linux vendors authentication services by setting following variables to any value.

WEBLATE_SOCIAL_AUTH_FEDORA¶

WEBLATE_SOCIAL_AUTH_OPENSUSE¶

WEBLATE_SOCIAL_AUTH_OPENINFRA¶

WEBLATE_SOCIAL_AUTH_UBUNTU¶

Slack¶

WEBLATE_SOCIAL_AUTH_SLACK_KEY¶

WEBLATE_SOCIAL_AUTH_SLACK_SECRET¶: Enables Slack authentication, see Slack.

OpenID Connect identity provider¶

Added in version 2026.11.

WEBLATE_OIDC_PROVIDER_ENABLED¶: Enable the optional OpenID Connect identity provider. Defaults to False. The image must include the oidc installation extra; see Configuration beyond environment variables. Enabling the provider installs its Django applications and migrations.

WEBLATE_OIDC_PROVIDER_RSA_PRIVATE_KEY_FILE¶: Required when WEBLATE_OIDC_PROVIDER_ENABLED is enabled. Path to a mounted, unencrypted RSA private key used to sign ID tokens. Generate it as described in OpenID Connect identity provider. Weblate does not generate this key. To retain inactive keys during rotation, configure OAUTH2_PROVIDER in settings-override.py.

OpenID Connect¶

Added in version 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT¶

WEBLATE_SOCIAL_AUTH_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_SECRET¶

WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_TITLE¶

WEBLATE_SOCIAL_AUTH_OIDC_IMAGE¶: Configures generic OpenID Connect integration.

Više informacija

OIDC (OpenID Connect)

Weblate OpenID Connect¶

Added in version 2026.11.

WEBLATE_SOCIAL_AUTH_WEBLATE_KEY¶

WEBLATE_SOCIAL_AUTH_WEBLATE_SECRET¶

Enable authentication through Hosted Weblate or another Weblate installation (see Weblate OpenID Connect) using the client ID and client secret registered with its OpenID Connect identity provider. Register the exact HTTPS callback URL of this installation, for example https://weblate.example.com/accounts/complete/weblate/.

environment:
  WEBLATE_SOCIAL_AUTH_WEBLATE_KEY: your-client-id
  WEBLATE_SOCIAL_AUTH_WEBLATE_SECRET_FILE: /run/secrets/weblate-client-secret

WEBLATE_SOCIAL_AUTH_WEBLATE_OIDC_ENDPOINT¶

Optional issuer URL. Defaults to https://hosted.weblate.org/oidc. For another installation, use its base URL followed by /oidc, including any deployment prefix, for example https://example.com/translations/oidc. Do not append /.well-known/openid-configuration.

Changing the issuer requires an explicit migration of existing account associations: the same subject identifier on different servers can refer to different people.

WEBLATE_SOCIAL_AUTH_WEBLATE_TITLE¶

WEBLATE_SOCIAL_AUTH_WEBLATE_IMAGE¶: Optional sign-in label and icon overrides. By default, the label is Hosted Weblate for Hosted Weblate and Weblate for other installations; both use the Weblate icon.

Više informacija

Weblate

Fedora OpenID Connect¶

Added in version 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET¶: Configures Fedora OpenID Connect integration.

Više informacija

Fedora

SAML¶

Self-signed SAML keys are automatically generated on first container startup. In case you want to use own keys, place the certificate and private key in /app/data/ssl/saml.crt and /app/data/ssl/saml.key.

WEBLATE_SAML_IDP_ENTITY_ID¶

WEBLATE_SAML_IDP_URL¶

WEBLATE_SAML_IDP_X509CERT¶

WEBLATE_SAML_IDP_IMAGE¶

WEBLATE_SAML_IDP_TITLE¶: SAML Identity Provider settings, see SAML autentifikacija.

WEBLATE_SAML_SECURITY_CONFIG¶

Added in version 2026.6.

SAML security configuration as a JSON object, passed to SOCIAL_AUTH_SAML_SECURITY_CONFIG. For example, to disable the requestedAuthnContext (needed for some identity providers such as Microsoft Entra ID with multi-factor authentication):

environment:
  WEBLATE_SAML_SECURITY_CONFIG: '{"requestedAuthnContext": false}'

Više informacija

python3-saml security settings

WEBLATE_SAML_ID_ATTR_FULL_NAME¶

WEBLATE_SAML_ID_ATTR_FIRST_NAME¶

WEBLATE_SAML_ID_ATTR_LAST_NAME¶

WEBLATE_SAML_ID_ATTR_USERNAME¶

WEBLATE_SAML_ID_ATTR_EMAIL¶

WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶: Added in version 4.18.

SAML attributes mapping.

Postavke ostalih autentifikacija¶

WEBLATE_NO_EMAIL_AUTH¶: Aktiviraj e-mail autentifikaciju kad je postavljena na bilo koju vrijednost. Pogledaj Isključivanje autentifikacije lozinkom.

WEBLATE_MIN_PASSWORD_SCORE¶

Minimal password score as evaluated by the zxcvbn password strength estimator. Defaults to 3, set to 0 to disable strength checking.

Više informacija

Postava PostgreSQL baze podataka¶

The database is created by docker-compose.yml, so these settings affect both Weblate and PostgreSQL containers.

Više informacija

Database setup for Weblate

POSTGRES_PASSWORD¶: PostgreSQL lozinka.

Više informacija

Passing secrets

POSTGRES_USER¶: PostgreSQL korisničko ime.

POSTGRES_DB¶: Ime PostgreSQL baze podataka.

POSTGRES_HOST¶: PostgreSQL server hostname or IP address. Defaults to database.

POSTGRES_PORT¶: PostgreSQL server port. Defaults to none (uses the default value).

POSTGRES_SSL_MODE¶: Configure how PostgreSQL handles SSL in connection to the server, for possible choices see SSL Mode Descriptions.

POSTGRES_ALTER_ROLE¶

Configures name of the PostgreSQL role to alter during the database migration, see Configuring Weblate to use PostgreSQL.

Defaults to POSTGRES_USER.

POSTGRES_CONN_MAX_AGE¶

Added in version 4.8.1.

The lifetime of a database connection, as an integer of seconds. Use 0 to close database connections at the end of each request.

Promijenjeno u verziji 5.1: The default behavior is to have unlimited persistent database connections.

Enabling connection persistence will typically, cause more open connection to the database. Please adjust your database configuration prior enabling.

Example configuration:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Više informacija

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Added in version 4.9.1.

Disable server side cursors in the database. This is necessary in some pgbouncer setups.

Example configuration:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Više informacija

WEBLATE_DATABASES¶: Added in version 5.1.

Set to false to disable environment based configuration of the database connection. Use Overriding settings from the data volume to configure the database connection manually.

Postavke sigurnosne kopije baze podataka¶

Više informacija

Dumped data for backups

WEBLATE_DATABASE_BACKUP¶: Configures the daily database dump using DATABASE_BACKUP. Defaults to plain.

Postavljanje servera za spremanje podataka¶

Using Valkey or Redis is required by the Weblate container and you have to provide a connection parameters when running Weblate in Docker.

Više informacija

Configure cache

REDIS_HOST¶: Ime hosta ili IP adresa servera za spremanje podataka. Zadana vrijednost je cache.

REDIS_PORT¶: Priljučak servera za spremanje podataka. Zadana vrijednost je 6379.

REDIS_DB¶: Broja baze podataka za spremanje podataka. Zadana vrijednost je 1.

REDIS_USER¶: Added in version 5.13: The datastore database user, not used by default.

REDIS_PASSWORD¶: The datastore server password, not used by default.

Više informacija

Passing secrets

REDIS_TLS¶: Enables using SSL for the datastore connection.

REDIS_VERIFY_SSL¶: Can be used to disable SSL certificate verification for the datastore connection.

Postavljanje e-mail servera¶

Za funkcioniranje slanja e-mailova moraš navesti e-mail server.

Primjer TLS konfiguracije:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

Primjer SSL konfiguracije:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_PORT: 465
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass
    WEBLATE_EMAIL_USE_TLS: 0
    WEBLATE_EMAIL_USE_SSL: 1

Više informacija

Configuring outgoing e-mail

WEBLATE_EMAIL_HOST¶

Ime računala e-mail servera ili IP sdresa.

Više informacija

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
WEBLATE_EMAIL_USE_TLS
EMAIL_HOST

WEBLATE_EMAIL_PORT¶: Priključak e-mail servera, zadano je 25.

Više informacija

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: Korisnik e-mail autentifikacije.

Više informacija

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶

Lozinka e-mail autentifikacije.

Više informacija

WEBLATE_EMAIL_USE_SSL¶

Whether to use an implicit TLS (secure) connection when talking to the SMTP server. In most e-mail documentation, this type of TLS connection is referred to as SSL. It is generally used on port 465. If you are experiencing problems, see the explicit TLS setting WEBLATE_EMAIL_USE_TLS.

Promijenjeno u verziji 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Više informacija

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_TLS
EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶

Whether to use a TLS (secure) connection when talking to the SMTP server. This is used for explicit TLS connections, generally on port 587 or 25. If you are experiencing connections that hang, see the implicit TLS setting WEBLATE_EMAIL_USE_SSL.

Promijenjeno u verziji 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Više informacija

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶

Konfigurira Djangov pozadinski sustav koji se koristi za slanje e-maila.

Set to django_ses.SESBackend to use AWS SES.

Više informacija

WEBLATE_AWS_SES_REGION_NAME¶: AWS region for SES (e.g. us-east-1). Sets AWS_SES_REGION_NAME and derives WEBLATE_AWS_SES_REGION_ENDPOINT automatically unless that variable is set explicitly. If not set, the region must be available through the standard boto3 credential chain (e.g. AWS_DEFAULT_REGION or an AWS profile).

WEBLATE_AWS_SES_REGION_ENDPOINT¶: SES endpoint hostname. When set, it is passed to django-ses directly regardless of WEBLATE_AWS_SES_REGION_NAME. When not set but WEBLATE_AWS_SES_REGION_NAME is provided, defaults to email.<region>.amazonaws.com. Override when using a VPC or custom endpoint.

WEBLATE_USE_SES_V2¶: Set to true to use the SES v2 API (SendEmail) instead of the legacy SendRawEmail call. Boolean setting (use "true" or "false").

WEBLATE_AUTO_UPDATE¶

Configures if and how Weblate should update repositories.

The default, "false", fetches remote changes daily without merging them into the working copy; it does not disable daily updates. Set to "true" to also merge remote changes into the working copy.

Više informacija

AUTO_UPDATE for details on how updates are scheduled throughout the day.

Napomena

This is a Boolean setting (use "true" or "false").

Integracija web stranice¶

WEBLATE_GET_HELP_URL¶: Configures GET_HELP_URL.

WEBLATE_STATUS_URL¶: Configures STATUS_URL.

WEBLATE_LEGAL_URL¶: Configures LEGAL_URL.

WEBLATE_PRIVACY_URL¶: Configures PRIVACY_URL.

WEBLATE_PASSWORD_RESET_URL¶: Configures PASSWORD_RESET_URL.

Collecting error reports and monitoring performance¶

It is recommended to collect errors from the installation systematically, see Collecting error reports and monitoring performance.

To enable support for Rollbar, set the following:

ROLLBAR_KEY¶: Your Rollbar post server access token.

ROLLBAR_ENVIRONMENT¶: Your Rollbar environment, defaults to production.

To enable support for Sentry, set following:

SENTRY_DSN¶: Your Sentry DSN, see SENTRY_DSN.

SENTRY_ENVIRONMENT¶: Your Sentry Environment (optional), defaults to WEBLATE_SITE_DOMAIN.

SENTRY_MONITOR_BEAT_TASKS¶: Whether to monitor Celery Beat tasks with Sentry, defaults to True.

SENTRY_TRACES_SAMPLE_RATE¶

Configures SENTRY_TRACES_SAMPLE_RATE.

Primjer:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

SENTRY_PROFILES_SAMPLE_RATE¶

Configures SENTRY_PROFILES_SAMPLE_RATE.

Primjer:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

SENTRY_SEND_PII¶: Configures SENTRY_SEND_PII.

To enable support for Google Cloud Error Reporting, set following:

GOOGLE_CLOUD_ERROR_REPORTING_ENABLED¶: Enables GOOGLE_CLOUD_ERROR_REPORTING, defaults to False.

GOOGLE_CLOUD_ERROR_REPORTING_PROJECT¶: Google Cloud project to report errors to. If omitted, the Google client uses application default credentials to detect the project.

GOOGLE_CLOUD_ERROR_REPORTING_SERVICE¶: Service name to use in Google Cloud Error Reporting, defaults to weblate.

To enable support for OpenTelemetry tracing, set following:

OPENTELEMETRY_ENABLED¶: Enables OPENTELEMETRY_ENABLED, defaults to False.

OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT¶

Configures OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT.

Primjer:

environment:
  OPENTELEMETRY_ENABLED: true
  OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT: https://collector.example.com/v1/traces
  OPENTELEMETRY_TRACES_SAMPLE_RATE: 0.1

OPENTELEMETRY_EXPORTER_OTLP_HEADERS¶: Configures OPENTELEMETRY_EXPORTER_OTLP_HEADERS as a comma-separated name:value mapping.

OPENTELEMETRY_EXTRA_RESOURCE_ATTRIBUTES¶: Configures OPENTELEMETRY_EXTRA_RESOURCE_ATTRIBUTES as a comma-separated name:value mapping.

OPENTELEMETRY_SERVICE_NAME¶: Configures OPENTELEMETRY_SERVICE_NAME.

OPENTELEMETRY_TRACES_SAMPLE_RATE¶: Configures OPENTELEMETRY_TRACES_SAMPLE_RATE.

Mreža za dostavljanje sadržaja (CDN) lokalizacije¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

Configuration for CDN add-ons, including CDN JavaScript lokalizacije and CDN prevodilačkih datoteka.

The WEBLATE_LOCALIZE_CDN_PATH is path within the container. It should be stored on the persistent volume and not in the transient storage.

One of possibilities is storing that inside the Weblate data dir:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

Napomena

You are responsible for setting up serving of the files generated by Weblate, it only stores the files in configured location. See Mreža za dostavljanje sadržaja (CDN) lokalizacije for secure serving guidance.

Više informacija

Changing enabled apps, checks, formats, add-ons, translation services, or autofixes¶

The built-in configuration of enabled checks, file formats, add-ons, translation services, or autofixes can be adjusted by the following variables:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_FORMATS¶

WEBLATE_REMOVE_FORMATS¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

WEBLATE_ADD_MACHINERY¶: Added in version 5.6.1.

WEBLATE_REMOVE_MACHINERY¶: Added in version 5.6.1.

Primjer:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_REMOVE_FORMATS: weblate.formats.ttkit.PoFormat
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

Više informacija

Postavke kontejnera¶

WEBLATE_WORKERS¶

Added in version 4.6.1.

Base number of worker processes running in the container. When not set it is determined automatically on container startup based on number of CPU cores available.

It is used to determine CELERY_MAIN_OPTIONS, CELERY_COMBINED_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, WEB_WORKERS, and WEB_BLOCKING_THREADS. You can use these settings to fine-tune.

CELERY_WORKER_MODE¶

Added in version 2026.9.1.

Selects how Celery workers are run in the container. Supported modes are:

combined: Runs one prefork worker for all queues. This is the default and reduces memory usage by sharing the application startup memory. Its concurrency defaults to three times WEBLATE_WORKERS, and its prefetch multiplier defaults to one.
split: Runs a separate prefork worker for each queue. This matches the behavior of container versions before 2026.9.1 and allows each queue to be tuned independently.
single: Runs all queues in one process using the solo pool. This minimizes memory usage, but noticeably reduces task throughput.

Explicit WEBLATE_SERVICE selection takes precedence over this setting in horizontally scaled deployments.

CELERY_COMBINED_OPTIONS¶

Added in version 2026.9.1.

Configures the worker used by CELERY_WORKER_MODE=combined. By default, its concurrency is three times WEBLATE_WORKERS. The worker uses a prefetch multiplier of one unless overridden here.

environment:
  CELERY_COMBINED_OPTIONS: --concurrency 12 --prefetch-multiplier 1

Više informacija

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

These variables allow you to adjust Celery worker options in CELERY_WORKER_MODE=split. It can be useful to adjust concurrency (--concurrency 16), prefetching (--prefetch-multiplier 4), or use different pool implementation (--pool=gevent). Command-line options take precedence over corresponding Celery settings, allowing each worker category to use a different prefetch multiplier. When any of these variables is set in combined or single mode, the container logs a startup warning that it is ignored.

By default, the number of concurrent workers is based on WEBLATE_WORKERS.

Primjer:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16 --prefetch-multiplier 1

Više informacija

CELERY_BEAT_OPTIONS¶: Configures the Celery beat scheduler in all worker modes.

CELERY_SINGLE_OPTIONS¶

Configures the worker used by CELERY_WORKER_MODE=single.

Više informacija

CELERY_SINGLE_PROCESS¶: Added in version 5.7.1.

Zastarijelo od verzije 2026.9.1.

Compatibility alias for CELERY_WORKER_MODE=single. When set to 1 without CELERY_WORKER_MODE, the container starts in single mode and logs a warning asking you to update the setting. If both variables are set, CELERY_WORKER_MODE takes precedence.

Više informacija

Single-process Celery setup

WEBLATE_ASGI¶

Added in version 2026.8.

Set to 1 to run the web application using ASGI instead of WSGI. This is an opt-in setting intended for testing the transition to ASGI. WSGI remains the default for now, but a future release will run ASGI only and remove this setting.

environment:
  WEBLATE_ASGI: 1

Više informacija

Sample configuration to start Granian with ASGI

WEB_WORKERS¶

Configure how many web application workers should be executed.

It defaults to half of WEBLATE_WORKERS, but is always at least 2.

Primjer:
environment:
  WEB_WORKERS: 4

Promijenjeno u verziji 5.13: WEB_WORKERS configures how many worker processes will be used by granian.

WEB_BLOCKING_THREADS¶

Configure how many blocking WSGI threads each granian worker can use. It defaults to twice WEBLATE_WORKERS and is ignored when WEBLATE_ASGI is enabled.

The maximum number of simultaneous WSGI requests is approximately WEB_WORKERS multiplied by WEB_BLOCKING_THREADS. Each thread can hold its own database connection, so keep the resulting total within the database connection limit.

Primjer:

environment:
  WEB_WORKERS: 2
  WEB_BLOCKING_THREADS: 8

WEBLATE_SERVICE¶

Defines which services should be executed inside the container. Use this for Scaling horizontally.

Following services are defined:

celery-beat: Celery task scheduler, only one instance should be running. This container is also responsible for the database structure migrations and it should be started prior others.
celery-backup: Celery worker for backups, only one instance should be running.
celery-combined: Combined Celery worker for all task queues.
celery-celery: Generic Celery worker.
celery-memory: Prevodilačka memorija Celery worker.
celery-notify: Celery worker obavijesti.
celery-single: Single-process Celery worker for all task queues.
celery-translate: Celery worker automatsko prevođenje.
web: Web server.

Više informacija

Background tasks internals

WEBLATE_ANUBIS_URL¶

Added in version 5.11.4.

URL of Anubis server to handle subrequest authentication. This can be useful to filter incoming HTTP requests using proof-of-work to stop AI crawlers. You need to configure Anubis for Subrequest Authentication to make it work.

Use an http:// or https:// URL with a valid hostname or IPv4 address. The URL can include a port and a simple slash-separated path using ASCII letters, digits, _, and -. Credentials, queries, fragments, and IPv6 addresses are not supported.

Više informacija

Anubis Docker container integration
Anubis

Docker container volumes¶

There are two volumes (data and cache) exported by the Weblate container.

Napomena

The other service containers (such as PostgreSQL or Valkey) have their data volumes as well and are required to maintain Weblate persistence.

The PostgreSQL container stores the database in the /var/lib/postgresql volume and Valkey in the /data volume. Valkey container does not save the data by default and needs additional configuration to enable persistence.

Base your configuration on Weblate-provided examples or consult their documentation for more information.

The data volume is mounted as /app/data and is used to store Weblate persistent data such as cloned repositories or to customize Weblate installation. DATA_DIR describes in more detail what is stored here.

The data volume is also place to store Weblate customization such as Overriding settings from the data volume, Replacing logo and other static files or Prilagođavanje koda.

The placement of the Docker volume on host system depends on your Docker configuration, but usually it is stored in /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (the path consist of name of your docker-compose directory, container, and volume names).

The cache volume is mounted as /app/cache and is used to store static files and CACHE_DIR. Its content is recreated on container startup and the volume can be mounted using ephemeral filesystem such as tmpfs, but the mount has to allow execution because Weblate stores generated helper files there.

When mounting /app/cache explicitly as tmpfs in Docker Compose, enable execution:

tmpfs:
  - /app/cache:exec

When also setting ownership options, keep the exec option:

tmpfs:
  - /app/cache:exec,uid=1000,gid=1000

When creating the volumes manually, the directories should be owned by UID 1000 as that is user used inside the container.

Weblate container can also be executed with a read-only root file system. In this case, two additional tmpfs volumes should be mounted: /tmp and /run.

Više informacija

Read-only root filesystem¶

Added in version 4.18.

When running the container with a read-only root filesystem, two additional tmpfs volumes are required - /tmp and /run.

Configuration beyond environment variables¶

Docker environment variables are intended to expose most configuration settings of relevance for Weblate installations.

If you find a setting that is not exposed as an environment variable, and you believe that it should be, feel free to ask for it to be exposed in a future version of Weblate.

If you need to modify a setting that is not exposed as a Docker environment variable, you can still do so, either from the data volume or extending the Docker image.

Više informacija

Customizing Weblate

Overriding settings from the data volume¶

You can create a file at /app/data/settings-override.py, i.e. at the root of the data volume, to extend or override settings defined through environment variables.

Overriding settings by extending the Docker image¶

To override settings at the Docker image level instead of from the data volume:

Create a custom Python package.
Add a module to your package that imports all settings from weblate.settings_docker.

For example, within the example package structure defined at Creating a Python module, you could create a file at weblate_customization/weblate_customization/settings.py with the following initial code:
```
from weblate.settings_docker import *
```

Create a custom Dockerfile that inherits from the official Weblate Docker image, and then installs your package and points the DJANGO_SETTINGS_MODULE environment variable to your settings module:

FROM weblate/weblate

USER root

COPY weblate_customization /usr/src/weblate_customization
RUN source /app/venv/bin/activate && uv pip install --no-cache-dir /usr/src/weblate_customization
ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings

USER 1000

Instead of using the official Weblate Docker image, build a custom image from this Dockerfile file.

There is no clean way to do this with docker-compose.override.yml. You could add build: . to the weblate node in that file, but then your custom image will be tagged as weblate/weblate in your system, which could be problematic.

So, instead of using the docker-compose.yml straight from the official repository, unmodified, and extending it through docker-compose.override.yml, you may want to make a copy of the official docker-compose.yml file, and edit your copy to replace image: weblate/weblate with build: ..

See the Compose file build reference for details on building images from source when using docker-compose.
Extend your custom settings module to define or redefine settings.

You can define settings before or after the import statement above to determine which settings take precedence. Settings defined before the import statement can be overridden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overridden.

You can also go further. For example, you can reproduce some of the things that weblate.docker_settings does, such as exposing settings as environment variables, or allow overriding settings from Python files in the data volume.

Replacing logo and other static files¶

The static files coming with Weblate can be overridden by placing into /app/data/python/customize/static (see Docker container volumes). For example creating /app/data/python/customize/static/favicon.ico will replace the favicon.

Savjet

The files are copied to the corresponding location upon container startup, so a restart of Weblate is needed after changing the content of the volume.

This approach can be also used to override Weblate templates. For example, custom Legal module documents and styles can be provided as described in Customizing legal documents and styles.

Alternatively you can also include own module (see Customizing Weblate) and add it as separate volume to the Docker container, for example:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

Prilagođavanje koda¶

Napomena

The internal Weblate API may vary significantly between releases and is not meant to be stable. Please review your custom code interacting with Weblate internals on each upgrade.

You can place additional Python code into /app/data/python/customize (see Docker container volumes). It is already installed as a Django application inside Weblate (this is used for customizing templates and static files as described above).

This can be used to place any code (for example Writing own checks) or to add custom maintenance tasks to the Celery task scheduler.

An example of custom scheduled tasks in /app/data/python/customize/tasks.py.¶

"""Custom scheduled task."""

from __future__ import annotations

# ruff: ignore[suspicious-subprocess-import]
import subprocess
from typing import TYPE_CHECKING

from celery.schedules import crontab

from weblate.utils.celery import app

if TYPE_CHECKING:
    from celery import Celery


@app.task
def custom_task() -> None:
    """Execute custom task code."""
    # ruff: ignore[start-process-with-partial-path]
    subprocess.run(["sleep", "1"], check=True)


@app.on_after_finalize.connect
def setup_periodic_tasks(sender: Celery, **kwargs: object) -> None:
    """Configure when periodic task is triggered."""
    sender.add_periodic_task(
        crontab(hour=1, minute=0), custom_task.s(), name="custom-task"
    )

Integrating third-party containers¶

The Weblate Docker setup can be extended with additional containers to provide complementary services such as machine translation, spell checking, or other tools that enhance the translation workflow. These services can be integrated into your Docker Compose configuration and work alongside Weblate.

When adding third-party containers, consider the following:

Network connectivity: Ensure containers can communicate with each other by placing them on the same Docker network
Data persistence: Use volumes for services that need to persist data
Security: Configure appropriate access controls and avoid exposing unnecessary ports

LibreTranslate Docker container integration¶

LibreTranslate is a free and open-source machine translation service that can be self-hosted. Integrating it with Weblate provides offline machine translation capabilities without relying on external services.

You can incorporate the LibreTranslate service into your Weblate deployment by including it in a docker-compose.override.yml file. Since it runs within the Docker network, it’s only accessible to Weblate and not exposed to the public internet.

Basic setup using docker-compose.override.yml:

services:
  libretranslate:
    image: libretranslate/libretranslate:latest
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s

volumes:
  libretranslate_models:

For GPU-accelerated translation (if you have NVIDIA GPU available):

services:
  libretranslate:
    image: libretranslate/libretranslate:latest-cuda
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
      PUID: root
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  libretranslate_models:

After starting the services with docker compose down && docker compose up -d, configure LibreTranslate in Weblate:

Access the Weblate admin interface
Navigate to Manage → Translation services
Add a new LibreTranslate service with:

Usluga:

LibreTranslate

URL API-a:

http://libretranslate:5000

API ključ:

Leave empty

LibreTranslate is now configured and available for machine translation in Weblate.

Napomena

The LibreTranslate service runs without the web UI (--disable-web-ui) and is only accessible via the API within the Docker network.
Models are automatically updated when the container starts. (LT_UPDATE_MODELS: true)
Data is persisted using Docker volumes for optimal performance and data safety.
Health checks ensure that the Docker engine properly observes the state of the service.
For GPU acceleration, use the CUDA image variant and ensure your system has NVIDIA Docker support. This container runs as a privileged user to be able to use the GPU.
No external ports are exposed, making the setup secure by default.

Više informacija

Anubis Docker container integration¶

Anubis is a web AI firewall utility to block AI scrapers and other disruptive traffic on the server. It is typically needed for publicly open Weblate installations to avoid excessive load caused by scraping.

Anubis can be deployed using Docker Compose:

anubis:
   image: ghcr.io/techarohq/anubis:latest
   environment:
      BIND: ":8923"
      DIFFICULTY: "4"
      METRICS_BIND: ":9090"
      SERVE_ROBOTS_TXT: "false"
      OG_PASSTHROUGH: "false"
      # The single space in TARGET enables subrequest authentication
      TARGET: " "
      # The redirect domain has to match WEBLATE_SITE_DOMAIN
      REDIRECT_DOMAINS: weblate.example.com
      # Generate a random private key using: openssl rand -hex 32
      ED25519_PRIVATE_KEY_HEX: "..."
      # Customize your Anubis policy
      POLICY_FNAME: /data/botPolicies.yaml
   healthcheck:
      test: ["CMD", "anubis", "--healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5
      start_period: 500ms
   volumes:
      - anubis-data:/data

volumes:
   anubis-data:

Napomena

The anubis-data volume in the above configuration is expected to contain botPolicies.yaml with a bot policy configured to your needs.

At minimum, you need to adjust status codes as described in https://anubis.techaro.lol/docs/admin/configuration/subrequest-auth.

It is also recommended to configure persistent storage backend as described in https://anubis.techaro.lol/docs/admin/policies/#storage-backends.

You can then turn on the Anubis usage in Weblate using:

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

Više informacija

WEBLATE_ANUBIS_URL

Application-aware proof of work¶

Added in version 2026.11.

This integration is a technology preview. See Anonymous bot protection for its stability and maintenance policy.

WEBLATE_BOT_PROTECTION_ENABLED¶

WEBLATE_BOT_PROTECTION_DIFFICULTY¶

WEBLATE_BOT_PROTECTION_CHALLENGE_AGE¶

WEBLATE_BOT_PROTECTION_COOKIE_AGE¶

WEBLATE_BOT_PROTECTION_CACHE_ALIAS¶

WEBLATE_BOT_PROTECTION_EXEMPT_PATHS¶

WEBLATE_BOT_PROTECTION_EXEMPT_AGENTS¶

WEBLATE_BOT_PROTECTION_CRAWLER_FILE¶

WEBLATE_BOT_PROTECTION_CRAWLER_RULES¶

WEBLATE_BOT_PROTECTION_UNWANTED_AGENTS¶

WEBLATE_BOT_PROTECTION_UNWANTED_ACTION¶

Enable Anonymous bot protection with WEBLATE_BOT_PROTECTION_ENABLED set to 1. The Django gate works without an Anubis container. During migration, remove WEBLATE_ANUBIS_URL from the container environment and recreate the container to remove the NGINX Anubis subrequest gate. Keeping both enabled can produce two challenges; application authentication cannot bypass an upstream Anubis challenge. Existing Anubis configuration and cookies are not modified or trusted by the application gate.

Every BOT_PROTECTION_* setting has a matching WEBLATE_BOT_PROTECTION_* environment variable: DIFFICULTY (4), CHALLENGE_AGE (300), COOKIE_AGE (3600), CACHE_ALIAS (default), EXEMPT_PATHS (empty list), EXEMPT_AGENTS (empty list), CRAWLER_FILE (empty), CRAWLER_RULES (empty JSON object), UNWANTED_AGENTS (empty list), and UNWANTED_ACTION (challenge). Lists use the standard comma-separated Docker setting syntax. Configure a persistent writable crawler snapshot and run weblate update_crawler_ranges daily from an external scheduler; application workers are not required. Use the existing shared cache for replay protection.

Set WEBLATE_BOT_PROTECTION_EXEMPT_AGENTS to comma-separated, case-insensitive User-Agent regular expressions for monitoring exemptions. For example, ^Weblate-Uptime/1\.0$ exempts a monitor using that exact agent. Matching requests bypass bot protection for all methods and paths, including unwanted-agent denial. This trusts a spoofable header and does not grant application access; see BOT_PROTECTION_EXEMPT_AGENTS.

HTTPS, trusted proxy IP handling, same-origin challenge assets, and bypassing shared proxy caches for protected application routes are required. Deployments with CDN-hosted static files must provide these challenge assets at the same origin as Weblate.

Configuring PostgreSQL server¶

The PostgreSQL container uses default PostgreSQL configuration and it won’t effectively utilize your CPU cores or memory. It is recommended to customize the configuration to improve the performance.

The configuration can be adjusted as described in Database Configuration at https://hub.docker.com/_/postgres. The configuration matching your environment can be generated using https://pgtune.leopard.in.ua/.

Container internals¶

The container is using supervisor to start individual services. In case of Scaling horizontally, it only starts single service in a container.

To check the services status use:

docker compose exec --user weblate weblate supervisorctl status

The Celery services depend on CELERY_WORKER_MODE. The default combined mode runs celery-combined, while single mode runs celery-single. You can stop all task processing in the default mode using:

docker compose exec --user weblate weblate supervisorctl stop celery-combined

The split mode runs an individual service for each Celery queue (see Background tasks using Celery for details). In this mode, you can stop processing some tasks by stopping the appropriate worker:

docker compose exec --user weblate weblate supervisorctl stop celery-translate