Installation via 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.

Exigences matérielles

Weblate devrait fonctionner sur n’importe quel matériel moderne sans problème, ce qui suit est la configuration minimale requise pour faire fonctionner Weblate sur un seul hôte (Weblate, base de données et serveur Web) :

  • 3 Go de RAM

  • processeur à deux coeurs

  • 1 Go d’espace de stockage

Note

Les exigences réelles pour votre installation de Weblate varient fortement en fonction de la taille des traductions qui y seront gérées.

Utilisation de la mémoire

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.

Indication

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

Utilisation du processeur

Beaucoup d’utilisateurs concurrents augmentent le nombre nécessaire de coeurs du processeur.

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.

Utilisation du stockage

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.

Noeuds

For small and medium-sized sites (millions of hosted words), all Weblate components (see Architecture overview) 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 Configuration de la base de données pour Weblate).

Installation

Indication

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 Certificats SSL automatiques via Let’s Encrypt. For larger setups, please see Scaling horizontally.

  1. Clonez le dépôt weblate-docker :

    git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

    Note

    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.

  2. Créez un fichier docker-compose.override.yml contenant vos paramètres. Consultez la documentation de variables d’environnement Docker pour obtenir la liste complète des variables d’environnement.

    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

    Note

    Si la variable d’environnement WEBLATE_ADMIN_PASSWORD n’est pas définie, l’utilisateur administrateur est créé avec un mot de passe aléatoire affiché au premier démarrage.

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

  3. Démarrer les conteneurs Weblate :

    docker compose up

Profitez de votre déploiement Weblate, il est accessible sur le port 80 du conteneur weblate.

Voir aussi

Appel des commandes de gestion

Choosing Docker image registry

Weblate containers are published to following registries:

Note

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

Description

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

Conteneur Docker avec prise en charge HTTPS

Veuillez consulter Installation pour les instructions de déploiement génériques, cette section mentionne uniquement les différences par rapport à celle-ci.

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 Fonctionnement derrière un proxy inverse.

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.

Utilisation de nos propres certificats SSL

Si vous possédez votre propre certificat SSL que vous souhaitez utiliser, placez simplement les fichiers dans le volume de données Weblate (voir Volumes du conteneur Docker) :

  • ssl/fullchain.pem contenant le certificat, y compris tous les certificats d’autorité de certification nécessaires

  • ssl/privkey.pem contenant la clé privée

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

De plus, le conteneur Weblate acceptera désormais les connexions SSL sur le port 4443 ; vous devrez inclure la redirection de port pour HTTPS dans la configuration Docker Compose :

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

Si vous hébergez déjà d’autres sites sur le même serveur, il est probable que les ports 80 et 443 soient utilisés par un proxy inverse, tel que NGINX. Pour rediriger la connexion HTTPS de NGINX vers le conteneur Docker, vous pouvez utiliser la configuration suivante :

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>;
    }
}

Remplacez <SITE_URL>, <SITE> et <EXPOSED_DOCKER_PORT> par les valeurs réelles de votre environnement.

Certificats SSL automatiques via 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

Mise à niveau du conteneur Docker

Il est généralement conseillé de ne mettre à jour que le conteneur Weblate et de conserver le conteneur PostgreSQL à sa version actuelle, car la mise à niveau de PostgreSQL est assez complexe et n’apporte généralement pas beaucoup d’avantages.

Vous pouvez le faire en conservant votre configuration docker-compose existante, en récupérant simplement les images les plus récentes, puis en redémarrant :

# 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

La base de données Weblate devrait être migrée automatiquement au premier démarrage, et aucune action manuelle supplémentaire ne devrait être nécessaire.

Note

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

Note

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.

Voir aussi

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

  1. Arrêtez le conteneur Weblate :

    docker compose stop weblate cache

  2. Backup the database:

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

  3. Stop the database container:

    docker compose stop database

  4. Supprimer le volume PostgreSQL :

    docker compose rm -v database
docker volume remove weblate-docker_postgres-data

    Indication

    The volume name contains name of the Docker Compose project, which is by default the directory name what is weblate-docker in this documentation.

  5. Adjust docker-compose.yml to use new PostgreSQL version.

  6. Start the database container:

    docker compose up -d database

  7. Restaurer la base de données à partir de la sauvegarde :

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

    Indication

    Please check that the database name matches POSTGRES_DB.

  8. (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'"

    Indication

    Please check that the database name matches POSTGRES_DB.

  9. Démarrer tous les conteneurs restants :

    docker compose up -d

Connexion en tant qu’administrateur

Une fois le conteneur configuré, vous pouvez vous connecter en tant qu’utilisateur admin avec le mot de passe fourni dans WEBLATE_ADMIN_PASSWORD, ou un mot de passe aléatoire généré au premier démarrage si celui-ci n’a pas été défini.

Pour réinitialiser le mot de passe admin, redémarrez le conteneur avec WEBLATE_ADMIN_PASSWORD défini sur le nouveau mot de passe.

Voir aussi

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

Voir aussi

Scaling horizontally

Ajouté dans la 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.

Paramétrage des avertissements au démarrage

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 Rapport de performance 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.

variables d’environnement Docker

Many of Weblate’s Configuration 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

Ajouté dans la 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

Voir aussi

How to use secrets in Docker Compose

Paramètres génériques

WEBLATE_DEBUG

Configure le mode débogage Django à l’aide de DEBUG.

Exemple:

environment:
  WEBLATE_DEBUG: 1

Voir aussi

Désactiver le mode débogage

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.

Pour une journalisation moins verbeuse, utilisez ERROR ou WARNING.

WEBLATE_LOGLEVEL_DATABASE

Configures the logging of the database queries verbosity.

WEBLATE_LOG_GELF_HOST

Ajouté dans la version 5.9.

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

WEBLATE_LOG_GELF_PORT

Ajouté dans la 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.

Exemple:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Voir aussi

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Configure le nom et l’adresse e-mail de l’administrateur du site. Cette configuration sert à la fois à paramétrer les administrateurs ADMINS et à créer l’utilisateur admin (voir la variable d’environnement WEBLATE_ADMIN_PASSWORD pour plus d’informations).

Exemple:

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

Voir aussi

WEBLATE_ADMIN_PASSWORD

Définit le mot de passe de l’utilisateur admin.

  • Si aucun utilisateur admin n’est défini et n’existe pas, il est créé avec un mot de passe aléatoire affiché lors du premier démarrage du conteneur.

  • Si cette option n’est pas activée et que l’utilisateur admin existe, aucune action n’est effectuée.

  • Si cette option est activée, l’utilisateur admin est ajusté à chaque démarrage du conteneur pour correspondre à WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME et WEBLATE_ADMIN_EMAIL.

Avertissement

Stocker le mot de passe dans le fichier de configuration peut présenter un risque pour la sécurité. Il est recommandé de n’utiliser cette variable que lors de la configuration initiale (ou de laisser Weblate générer un mot de passe aléatoire au premier démarrage) ou pour la récupération du mot de passe.

Voir aussi

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.

Voir aussi

WEBLATE_SERVER_EMAIL

The email address that error messages are sent from.

Voir aussi

WEBLATE_DEFAULT_FROM_EMAIL

Configure l’adresse des courriels sortants.

Voir aussi

WEBLATE_ADMINS_CONTACT

Configures ADMINS_CONTACT.

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.

Exemple:

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

Voir aussi

WEBLATE_REGISTRATION_OPEN

Configure si les inscriptions sont ouvertes en basculant REGISTRATION_OPEN.

Exemple:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
WEBLATE_REGISTRATION_CAPTCHA

Ajouté dans la version 5.10.

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

Exemple:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0
WEBLATE_REGISTRATION_ALLOW_BACKENDS

Configurez les méthodes d’authentification pouvant être utilisées pour créer un nouveau compte via REGISTRATION_ALLOW_BACKENDS.

Exemple:

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

Ajouté dans la version 4.16.

Configures REGISTRATION_REBIND.

WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS

Ajouté dans la version 5.16.1.

Configures REGISTRATION_ALLOW_DISPOSABLE_EMAILS.

Exemple:

environment:
  WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS: 1
WEBLATE_PROJECT_WEB_RESTRICT_PRIVATE

Ajouté dans la version 5.17.

Configures PROJECT_WEB_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_PROJECT_WEB_RESTRICT_ALLOWLIST

Ajouté dans la version 5.17.

Configures PROJECT_WEB_RESTRICT_ALLOWLIST.

Expects a comma-separated list of trusted project slugs.

WEBLATE_WEBHOOK_RESTRICT_PRIVATE

Ajouté dans la version 5.17.

Configures WEBHOOK_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_WEBHOOK_PRIVATE_ALLOWLIST

Ajouté dans la version 5.17.

Configures WEBHOOK_PRIVATE_ALLOWLIST.

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

WEBLATE_ALLOWED_ASSET_SIZE

Ajouté dans la version 2025.7.

Configures ALLOWED_ASSET_SIZE.

WEBLATE_ASSET_RESTRICT_PRIVATE

Ajouté dans la version 2025.5.

Configures ASSET_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_ASSET_PRIVATE_ALLOWLIST

Ajouté dans la version 2025.5.

Configures ASSET_PRIVATE_ALLOWLIST.

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

WEBLATE_TIME_ZONE

Configure le fuseau horaire utilisé dans Weblate, voir TIME_ZONE.

Note

Pour modifier le fuseau horaire du conteneur Docker lui-même, utilisez la variable d’environnement TZ.

Exemple:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague
WEBLATE_ENABLE_HTTPS

Cela permet à Weblate de supposer qu’il fonctionne derrière un proxy HTTPS inverse, d’utiliser le protocole HTTPS dans les e-mails et les liens API ou de définir des indicateurs de sécurité sur les cookies.

Indication

Please see ENABLE_HTTPS documentation for possible caveats.

Note

Cela ne permet pas au conteneur Weblate d’accepter les connexions HTTPS, vous devez également le configurer, voir Conteneur Docker avec prise en charge HTTPS pour des exemples.

Exemple:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Voir aussi

WEBLATE_NGINX_IPV6

Ajouté dans la version 5.17.

Controls whether the bundled NGINX listens on IPv6 addresses.

Supported values are:

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

Exemple:

environment:
  WEBLATE_NGINX_IPV6: auto
WEBLATE_IP_PROXY_HEADER

Permet à Weblate de récupérer l’adresse IP à partir de n’importe quel en-tête HTTP. Utilisez cette fonction lorsque vous utilisez un proxy inverse devant le conteneur Weblate.

Active IP_BEHIND_REVERSE_PROXY et définit 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.

Modifié dans la version 2026.9: The bundled nginx no longer trusts X-Forwarded-For from all network addresses. Trusted proxy addresses have to be configured explicitly.

Note

Le format doit être conforme aux attentes de Django. Django transforme les noms d’en-têtes HTTP bruts comme suit :

  • convertit en majuscules tous les caractères

  • remplace chaque tiret par un caractère de soulignement

  • ajoute le préfixe HTTP_

Ainsi, X-Forwarded-For serait mappé sur HTTP_X_FORWARDED_FOR.

Exemple:

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

Ajouté dans la 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.

Exemple:

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

Ajouté dans la 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

Ajouté dans la 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.

Voir aussi

USE_X_FORWARDED_PORT

Note

C’est une valeur booléenne (utiliser "true" ou "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.

Exemple:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Voir aussi

WEBLATE_REQUIRE_LOGIN

Enables REQUIRE_LOGIN to enforce authentication on whole Weblate.

Exemple:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

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

Supported values are:

  • 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 Remplacement du logo et des autres fichiers statiques.

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.

Exemple:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm

Voir aussi

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.

Exemple:

environment:
  WEBLATE_LEGAL_DOCUMENT_CSS_CLASS: ""

Configures LEGAL_HIDDEN_DOCUMENTS in Docker deployments with WEBLATE_LEGAL_INTEGRATION enabled.

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

External legal documents are used as fallbacks for hidden internal pages. The following configuration links both documents externally and requires one agreement covering the terms of service and privacy policy:

Exemple:

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

Configure l’ID pour Google Analytics en modifiant GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE

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

Voir aussi

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES

Configure la politique de simplification linguistique, voir SIMPLIFY_LANGUAGES.

WEBLATE_HIDE_SHARED_GLOSSARY_COMPONENTS

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

WEBLATE_DEFAULT_ACCESS_CONTROL

Configure le Contrôle d’accès par défaut pour les nouveaux projets, voir DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_TRANSLATION_REVIEW

Ajouté dans la version 5.16.

Configures the default value for Activer les révisions, turned off by default.

WEBLATE_DEFAULT_SOURCE_REVIEW

Ajouté dans la version 5.16.

Configures the default value for Activer la révision des chaînes sources, turned off by default.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT

Configure la valeur par défaut de Accès restreint pour les nouveaux composants, voir DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION

Configure la valeur par défaut de Permettre la propagation de la traduction pour les nouveaux composants, voir 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

Configures DEFAULT_AUTOCLEAN_TM.

WEBLATE_COMMIT_PENDING_HOURS

Configures the default value for Âge des modifications à commiter for new components, see COMMIT_PENDING_HOURS.

WEBLATE_GPG_IDENTITY

Configure la signature GPG des commits, voir WEBLATE_GPG_IDENTITY.

Voir aussi

Signature des commits Git avec GnuPG

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

Configure les contrôles que vous ne souhaitez pas afficher, voir 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.

Voir aussi

WEBLATE_LICENSE_FILTER

Configure LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Configures LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED

Configures WEBSITE_REQUIRED.

WEBLATE_VERSION_DISPLAY

Configures VERSION_DISPLAY.

WEBLATE_HIDE_VERSION

Configure HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES

Configure BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH

Configures DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS
WEBLATE_RATELIMIT_LOCKOUT
WEBLATE_RATELIMIT_WINDOW

Ajouté dans la version 4.6.

Configures rate limiter.

Indication

You can set configuration for any rate limiter scopes. To do that add WEBLATE_ prefix to any of setting described in Limite de requêtes.

Voir aussi

WEBLATE_API_RATELIMIT_ANON
WEBLATE_API_RATELIMIT_USER

Ajouté dans la version 4.11.

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

Voir aussi

API rate limiting

WEBLATE_API_RATELIMIT_USER_OVERRIDES
WEBLATE_API_RATELIMIT_IP_OVERRIDES

Ajouté dans la 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

Ajouté dans la version 4.13.

Configures ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS

Ajouté dans la version 4.6.1.

Configures ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX

Ajouté dans la version 4.15.

Configures AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH

Ajouté dans la version 4.9.

Configure LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS

Ajouté dans la version 4.9.

Configures SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS

Ajouté dans la version 4.9.

Configures BORG_EXTRA_ARGS as a comma separated list of args.

Exemple:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
WEBLATE_ENABLE_SHARING

Ajouté dans la version 4.14.1.

Configures ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK

Ajouté dans la version 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD

Ajouté dans la version 4.15.

Configures EXTRA_HTML_HEAD.

WEBLATE_INTERNAL_BOT_EMAIL_TEMPLATE

Ajouté dans la version 2026.7.1.

Configures INTERNAL_BOT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE

Ajouté dans la version 4.15.

Configures PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN

Ajouté dans la version 4.15.

Configures PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE

Ajouté dans la version 5.16.

Configures PRIVATE_COMMIT_NAME_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN

Ajouté dans la version 5.16.

Configures PRIVATE_COMMIT_NAME_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS

Ajouté dans la version 4.17.

Configures UNUSED_ALERT_DAYS.

WEBLATE_REPORT_EXPIRY

Ajouté dans la version 2026.8.

Configures REPORT_EXPIRY.

WEBLATE_UPDATE_LANGUAGES

Ajouté dans la version 4.3.2.

Configures UPDATE_LANGUAGES.

WEBLATE_VCS_ALLOW_HOSTS

Ajouté dans la version 5.15.

Configures VCS_ALLOW_HOSTS.

WEBLATE_VCS_PRIVATE_ALLOWLIST

Ajouté dans la version 2026.9.

Configures VCS_PRIVATE_ALLOWLIST.

WEBLATE_VCS_ALLOW_SCHEMES

Ajouté dans la version 5.15.

Configures VCS_ALLOW_SCHEMES.

WEBLATE_VCS_RESTRICT_PRIVATE

Ajouté dans la version 5.17.

Configures VCS_RESTRICT_PRIVATE.

WEBLATE_VCS_CLONE_DEPTH

Ajouté dans la version 5.4.

Configures VCS_CLONE_DEPTH.

WEBLATE_VCS_API_DELAY

Ajouté dans la version 5.4.

Configures VCS_API_DELAY.

WEBLATE_VCS_API_TIMEOUT

Ajouté dans la version 5.15.

Configures VCS_API_TIMEOUT.

WEBLATE_CORS_ALLOWED_ORIGINS

Ajouté dans la version 4.16.

Allow CORS requests to API from given origins.

Exemple:

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

Ajouté dans la version 5.6.1: Allows CORS requests to API from all origins.

WEBLATE_WEBSITE_ALERTS_ENABLED

Ajouté dans la version 5.17.

Configures WEBSITE_ALERTS_ENABLED.

CLIENT_MAX_BODY_SIZE

Ajouté dans la 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

Indication

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Certificats SSL automatiques via 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

Ajouté dans la version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_MEMBERS.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE

Ajouté dans la version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE

Ajouté dans la version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE

Ajouté dans la version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO

Ajouté dans la 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 Requêtes de fusion GitHub, but apply to all Intégration avec le système de contrôle de versions with appropriately changed variable names.

Important

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", } }'

Ou le chemin vers un fichier contenant le dictionnaire Python :

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 Requêtes de fusion GitHub by changing GITHUB_CREDENTIALS.

Voir aussi

Configuring code-hosting credentials in Docker

WEBLATE_GITHUB_LEGACY_APP_WEBHOOK_SECRET

Ajouté dans la 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 Requêtes de fusion GitLab by changing GITLAB_CREDENTIALS.

Voir aussi

Configuring code-hosting credentials in Docker

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Configures Tirages Gitea demandés by changing GITEA_CREDENTIALS.

Voir aussi

Configuring code-hosting credentials in Docker

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Configures Requêtes de fusion Pagure by changing PAGURE_CREDENTIALS.

Voir aussi

Configuring code-hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Configures Tirages demandés du Bitbucket Data Center by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME
WEBLATE_BITBUCKETCLOUD_WORKSPACE
WEBLATE_BITBUCKETCLOUD_TOKEN
WEBLATE_BITBUCKETCLOUD_HOST
WEBLATE_BITBUCKETCLOUD_CREDENTIALS

Configures Requêtes de pull de Bitbucket Cloud by changing BITBUCKETCLOUD_CREDENTIALS.

Voir aussi

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 Poussées Azure DevOps demandées by changing AZURE_DEVOPS_CREDENTIALS.

Voir aussi

Configuring code-hosting credentials in Docker

Automatic suggestion settings

Modifié dans la version 4.13: Automatic suggestion services are now configured in the user interface, see Suggestions automatiques.

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

Paramètres d’authentification

Indication

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_FILTER
WEBLATE_AUTH_LDAP_USER_SEARCH_UNION
WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER

Configuration de l’authentification LDAP.

Exemple de liaison directe :

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

Exemple de recherche et de liaison :

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

Exemple de recherche et de liaison avec 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)

Voir aussi

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

Active S’authentifier avec GitHub.

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 Authentification GitHub EE.

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET

Active S’authentifier avec Bitbucket.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY
WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET

Active 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

Active Google OAuth 2.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL

Active GitLab OAuth 2.

Gitea

WEBLATE_SOCIAL_AUTH_GITEA_API_URL
WEBLATE_SOCIAL_AUTH_GITEA_KEY
WEBLATE_SOCIAL_AUTH_GITEA_SECRET

Active l’authentification Gitea.

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

Ajouté dans la version 5.17.

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

Indication

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

Fournisseurs Linux

Vous pouvez activer l’authentification en utilisant les services d’authentification des fournisseurs Linux en définissant les variables suivantes à n’importe quelle valeur.

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

Active l’authentification Slack, voir Slack.

OpenID Connect

Ajouté dans la 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.

Voir aussi

OIDC (OpenID Connect)

Fedora OpenID Connect

Ajouté dans la version 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY
WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET

Configures Fedora OpenID Connect integration.

Voir aussi

Fedora

SAML

Les clés SAML auto-signées sont générées automatiquement au premier démarrage du conteneur. Si vous souhaitez utiliser vos propres clés, placez le certificat et la clé privée dans /app/data/ssl/saml.crt et /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

Paramètres du fournisseur d’identité SAML, voir S’authentifier avec SAML.

WEBLATE_SAML_SECURITY_CONFIG

Ajouté dans la 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}'

Voir aussi

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

Ajouté dans la version 4.18.

SAML attributes mapping.

Autres paramètres d’authentification

WEBLATE_NO_EMAIL_AUTH

Disables e-mail authentication when set to any value. See Désactiver l’authentification par mot de passe.

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.

Voir aussi

Configuration de la base de données PostgreSQL

La base de données est créée par docker-compose.yml, donc ces paramètres affectent à la fois les conteneurs Weblate et PostgreSQL.

Voir aussi

Configuration de la base de données pour Weblate

POSTGRES_PASSWORD

Mot de passe PostgreSQL.

Voir aussi

Passing secrets

POSTGRES_USER

Nom d’utilisateur PostgreSQL.

POSTGRES_DB

Nom de la base de données PostgreSQL.

POSTGRES_HOST

Nom d’hôte ou adresse IP du serveur PostgreSQL. Par défaut : database.

POSTGRES_PORT

Port du serveur PostgreSQL. Par défaut : aucun (utilise la valeur par défaut).

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 Configurer Weblate pour utiliser PostgreSQL.

Defaults to POSTGRES_USER.

POSTGRES_CONN_MAX_AGE

Ajouté dans la 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.

Modifié dans la version 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.

Exemple de configuration :

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Voir aussi

POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Ajouté dans la version 4.9.1.

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

Exemple de configuration :

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Voir aussi

WEBLATE_DATABASES

Ajouté dans la 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.

Paramètres de sauvegarde de la base de données

Voir aussi

Données supprimées pour les sauvegardes

WEBLATE_DATABASE_BACKUP

Configure la sauvegarde quotidienne de la base de données à l’aide de DATABASE_BACKUP. Par défaut : plain.

Datastore server setup

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

Voir aussi

Configure cache

REDIS_HOST

The datastore server hostname or IP address. Defaults to cache.

REDIS_PORT

The datastore server port. Defaults to 6379.

REDIS_DB

The datastore database number, defaults to 1.

REDIS_USER

Ajouté dans la version 5.13: The datastore database user, not used by default.

REDIS_PASSWORD

The datastore server password, not used by default.

Voir aussi

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.

Configuration du serveur de courriel

Pour que les courriels sortants fonctionnent, vous devez fournir un serveur de courrier.

Exemple de configuration TLS :

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

Exemple de configuration SSL :

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

Voir aussi

Configuration des e-mails sortants

WEBLATE_EMAIL_HOST

Nom d’hôte ou adresse IP du serveur de courrier.

Voir aussi

WEBLATE_EMAIL_PORT

Port du serveur de courrier, par défaut 25.

Voir aussi

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER

Utilisateur authentifié par adresse courriel.

Voir aussi

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD

Mot de passe d’authentification par adresse courriel.

Voir aussi

WEBLATE_EMAIL_USE_SSL

Indique s’il faut utiliser une connexion TLS implicite (sécurisée) lors des échanges avec le serveur SMTP. Dans la plupart des documentations sur le courriel, ce type de connexion TLS est appelé SSL. Il est généralement utilisé sur le port 465. Si vous rencontrez des problèmes, consultez le paramètre TLS explicite WEBLATE_EMAIL_USE_TLS.

Modifié dans la version 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Voir aussi

WEBLATE_EMAIL_USE_TLS

Indique s’il faut utiliser une connexion TLS (sécurisée) lors des échanges avec le serveur SMTP. Ceci est utilisé pour les connexions TLS explicites, généralement sur le port 587 ou 25. Si vous rencontrez des connexions qui restent bloquées, consultez le paramètre TLS implicite WEBLATE_EMAIL_USE_SSL.

Modifié dans la version 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Voir aussi

WEBLATE_EMAIL_BACKEND

Configures Django back-end to use for sending e-mails.

Set to django_ses.SESBackend to use AWS SES.

Voir aussi

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.

Voir aussi

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

Note

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

Site integration

WEBLATE_GET_HELP_URL

Configures GET_HELP_URL.

WEBLATE_STATUS_URL

Configures STATUS_URL.

Configures LEGAL_URL.

WEBLATE_PRIVACY_URL

Configures PRIVACY_URL.

WEBLATE_PASSWORD_RESET_URL

Configures PASSWORD_RESET_URL.

Collecting error reports and monitoring performance

Il est recommandé de collecter systématiquement les erreurs de l’installation, voir Collecting error reports and monitoring performance.

Pour activer la prise en charge de Rollbar, définissez ce qui suit :

ROLLBAR_KEY

Votre jeton d’accès au serveur d’envoi de Rollbar.

ROLLBAR_ENVIRONMENT

Votre environnement Rollbar, par défaut production.

Pour activer la prise en charge de Sentry, définissez ce qui suit :

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.

Exemple:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5
SENTRY_PROFILES_SAMPLE_RATE

Configures SENTRY_PROFILES_SAMPLE_RATE.

Exemple:

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.

Exemple:

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.

CDN de localisation

WEBLATE_LOCALIZE_CDN_URL
WEBLATE_LOCALIZE_CDN_PATH

Ajouté dans la version 4.2.1.

Configuration for CDN add-ons, including JavaScript localisation CDN and Fichiers de traduction CDN.

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

Note

You are responsible for setting up serving of the files generated by Weblate, it only stores the files in configured location. See CDN de localisation for secure serving guidance.

Voir aussi

Changing enabled apps, checks, formats, add-ons, machinery, or autofixes

The built-in configuration of enabled checks, file formats, add-ons, machinery, 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

Ajouté dans la version 5.6.1.

WEBLATE_REMOVE_MACHINERY

Ajouté dans la version 5.6.1.

Exemple:

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

Voir aussi

Paramètres du conteneur

WEBLATE_WORKERS

Ajouté dans la 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

Ajouté dans la 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

Ajouté dans la 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

Voir aussi

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.

Exemple:

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

Voir aussi

CELERY_BEAT_OPTIONS

Configures the Celery beat scheduler in all worker modes.

CELERY_SINGLE_OPTIONS

Configures the worker used by CELERY_WORKER_MODE=single.

Voir aussi

CELERY_SINGLE_PROCESS

Ajouté dans la version 5.7.1.

Obsolète depuis la version 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.

Voir aussi

Single-process Celery setup

WEBLATE_ASGI

Ajouté dans la 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

Voir aussi

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.

Exemple:

environment:
  WEB_WORKERS: 4

Modifié dans la version 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.

Exemple:

environment:
  WEB_WORKERS: 2
  WEB_BLOCKING_THREADS: 8
WEBLATE_SERVICE

Définit les services à exécuter à l’intérieur du conteneur. Utiliser ceci pour Scaling horizontally.

Les services suivants sont définis :

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

Mémoire de traduction Celery worker.

celery-notify

Notification de Celery worker.

celery-single

Single-process Celery worker for all task queues.

celery-translate

Traduction automatique de Celery worker.

web

Serveur web.

Voir aussi

Background tasks internals

WEBLATE_ANUBIS_URL

Ajouté dans la 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.

Voir aussi

Volumes du conteneur Docker

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

Note

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, Remplacement du logo et des autres fichiers statiques or Customizing code.

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.

Voir aussi

Read-only root filesystem

Ajouté dans la 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.

Voir aussi

Personnaliser 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:

  1. Create a custom Python package.

  2. Add a module to your package that imports all settings from weblate.settings_docker.

    For example, within the example package structure defined at Création d’un module Python, you could create a file at weblate_customization/weblate_customization/settings.py with the following initial code:

    from weblate.settings_docker import *

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

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

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

Remplacement du logo et des autres fichiers statiques

Les fichiers statiques fournis avec Weblate peuvent être remplacés en les plaçant dans /app/data/python/customize/static (voir Volumes du conteneur Docker). Par exemple, créer /app/data/python/customize/static/favicon.ico remplacera le favicon.

Indication

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.

Vous pouvez également inclure votre propre module (voir Personnaliser Weblate) et l’ajouter comme volume séparé au conteneur Docker, par exemple :

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

Customizing code

Note

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 Volumes du conteneur Docker). 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 Rédiger ses propres contrôles) 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:

  1. Access the Weblate admin interface

  2. Navigate to Machine translation → Automatic suggestions

  3. Add a new LibreTranslate service with:

    Service:

    LibreTranslate

    URL de l’API:

    http://libretranslate:5000

    Clé d’API:

    Leave empty

LibreTranslate est désormais paramétré et disponible pour les traductions automatisées dans Weblate.

Note

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

Voir aussi

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:

Note

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

Voir aussi

WEBLATE_ANUBIS_URL

Configuration du serveur PostgreSQL en cours

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.

Pour vérifier l’état des services, utiliser :

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 Tâches en arrière-plan utilisant 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