Instalar con 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 Redis as a caching backend.

Requisitos de hardware¶

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 webserver):

3 GB of RAM
2 núcleos de CPU
1 GB de espacio de almacenamiento

Cuanta más memoria tenga, mejor, ya que se utiliza para el prealmacenaje en todos los niveles (sistema de archivos, base de datos y Weblate).

Many concurrent users increases the amount of needed CPU cores. For hundreds of translation components at least 4 GB of RAM is recommended.

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.

Nota

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

Consejo

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

Instalación¶

Consejo

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 Certificados SSL automáticos con Let’s Encrypt. For larger setups, please see Scaling horizontally.

Clone el repositorio weblate-docker:

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

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

version: '3'
services:
  weblate:
    ports:
      - 80:8080
    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

Nota

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.

Inicie los contenedores de Weblate:
```
docker compose up
```

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

Ver también

Invocar órdenes de gestión

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

Nota

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:

Nombre de la etiqueta	Descripción	Caso de uso
`latest`	Weblate stable release, matches latest tagged release	Rolling updates in a production environment
`<MAJOR>`	Versión estable de Weblate	Rolling updates within a major version in a production environment
`<MAJOR>.<MINOR>`	Versión estable de Weblate	Rolling updates within a minor version in a production environment
`<VERSION>.<PATCH>`	Versión estable de Weblate	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	Rollling 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

Contenedor Docker con compatibilidad con HTTPS¶

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

Utilizar certificados SSL propios¶

In case you have own SSL certificate you want to use, simply place the files into the Weblate data volume (see Volúmenes de contenedores Docker):

ssl/fullchain.pem, que contiene el certificado SSL y cualquier certificado CA que se necesite
ssl/privkey.pem, que contiene la clave privada

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.

Certificados SSL automáticos con 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

Actualizar el contenedor de Docker¶

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.

Distinto en la versión 4.17-1: Since Weblate 4.17-1, the Docker container uses Django 4.2 what requires PostgreSQL 12 or newer, please upgrade it prior to upgrading Weblate. See Actualización del contenedor de PostgreSQL.

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.

Nota

Upgrades across major versions are not supported by Weblate. For example, if you are on 3.x series and want to upgrade to 4.x, first upgrade to the latest 4.0.x-y image (at time of writing this it is the 4.0.4-5), which will do the migration and then continue upgrading to newer versions.

You might also want to update the docker-compose repository, though it’s not needed in most case. See Actualización del contenedor de PostgreSQL for upgrading the PostgreSQL server.

Actualización del contenedor de PostgreSQL¶

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.

Ver también

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

Detener el contenedor de Weblate:
```
docker compose stop weblate cache
```

Backup the database:

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

Detenga el contenedor de la base de datos:
```
docker compose stop database
```
Elimine el volumen PostgreSQL:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
Consejo

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.
Inicie el contenedor de la base de datos:
```
docker compose up -d database
```
Restaurar la base de datos a partir de la copia de seguridad:
```
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
Consejo

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'"
```
Consejo

Please check that the database name matches POSTGRES_DB.
Inicie todos los contenedores restantes:
```
docker compose up -d
```

Iniciar la sesión cómo administrador¶

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.

Ver también

WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

Number of processes and memory consumption¶

The number of worker processes for both uWSGI 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.

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

environment:
  WEBLATE_WORKERS: 2

También puede ajustar las categorías individuales de los trabajadores:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

Ver también

WEBLATE_WORKERS CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, WEB_WORKERS

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 ordering of the services matters as well.

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

Docker environment variables¶

Many of Weblate’s Configuración 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

Ver también

How to use secrets in Docker Compose

Generic settings¶

WEBLATE_DEBUG¶

Configures Django debug mode using DEBUG.

Ejemplo:

environment:
  WEBLATE_DEBUG: 1

Ver también

Desactivar el modo de depuración

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_SITE_TITLE¶: Modifica el título del sitio que se muestra en la cabecera de todas las páginas.

WEBLATE_SITE_DOMAIN¶: Configura el dominio del sitio. Este parámetro es obligatorio.

Ver también

Set correct site domain, SITE_DOMAIN

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

Ejemplo:

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

Ver también

Iniciar la sesión cómo administrador, Properly configure admins, ADMINS

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.

Advertencia

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.

Ver también

Iniciar la sesión cómo administrador, Passing secrets, WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

WEBLATE_SERVER_EMAIL¶: The email address that error messages are sent from.

Ver también

SERVER_EMAIL, Configure e-mail sending

WEBLATE_DEFAULT_FROM_EMAIL¶: Configures the address for outgoing e-mails.

Ver también

DEFAULT_FROM_EMAIL, Configure e-mail sending

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.

El valor predeterminado es *, que permite todos los nombres de anfitrión.

Ejemplo:

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

Ver también

ALLOWED_HOSTS, Allowed hosts setup, Set correct site domain

WEBLATE_REGISTRATION_OPEN¶

Configures whether registrations are open by toggling REGISTRATION_OPEN.

Ejemplo:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

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

Ejemplo:

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_TIME_ZONE¶

Configura el huso horario utilizado en Weblate; vea TIME_ZONE.

Nota

Para cambiar el huso horario del contenedor Docker, utilice la variable de entorno TZ.

Ejemplo:

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.

Consejo

Please see ENABLE_HTTPS documentation for possible caveats.

Nota

Esto no hace que el contenedor de Weblate acepte las conexiones HTTPS; debe configurarlas también. Vea Contenedor Docker con compatibilidad con HTTPS para obtener ejemplos.

Ejemplo:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Ver también

ENABLE_HTTPS Set correct site domain, WEBLATE_SECURE_PROXY_SSL_HEADER

WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶: Added in version 4.12.1.

Lets Weblate set the meta[name=monetization] field in the head of the document. If multiple are specified, chooses one randomly.

Ver también

INTERLEDGER_PAYMENT_POINTERS

WEBLATE_IP_PROXY_HEADER¶

Permite que Weblate recupere la dirección IP de cualquier cabecera HTTP que se indique. Utilice esta variable si usa un «proxy» inverso ante el contenedor de Weblate.

Enables IP_BEHIND_REVERSE_PROXY and sets IP_PROXY_HEADER.

Nota

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

convierte todas las letras en mayúsculas
sustituye cualquier guion por guiones bajos
antepone el prefijo HTTP_

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

Ejemplo:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_IP_PROXY_OFFSET¶: Added in version 5.0.1.

Configures IP_PROXY_OFFSET.

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.

Ver también

USE_X_FORWARDED_PORT

Nota

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

WEBLATE_SECURE_PROXY_SSL_HEADER¶

A tuple representing a 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.

Ejemplo:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Ver también

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN¶

Enables REQUIRE_LOGIN to enforce authentication on whole Weblate.

Ejemplo:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

Adds URL exceptions for authentication required for the whole Weblate installation using LOGIN_REQUIRED_URLS_EXCEPTIONS.

You can either replace whole settings, or modify default value using ADD and REMOVE variables.

To enforce authentication for the contact form, do:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$

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

Ver también

DEFAULT_PULL_MESSAGE

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

WEBLATE_DEFAULT_ACCESS_CONTROL¶: Configures the default Control de acceso for new projects, see DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: Configures the default value for Acceso restringido for new components, see DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: Configures the default value for Permitir propagación de traducciones for new components, see DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL¶: Configura DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME¶: Configura DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM¶: Configura DEFAULT_SHARED_TM.

WEBLATE_AKISMET_API_KEY¶: Configura la clave de API de Akismet; vea AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY¶: Configura la firma con GPG de las consignas; vea WEBLATE_GPG_IDENTITY.

Ver también

Signing Git commits with GnuPG

WEBLATE_URL_PREFIX¶: Configures URL prefix where Weblate is running, see URL_PREFIX.

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¶: Allows to customize Content-Security-Policy HTTP header.

Ver también

Content security policy, CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

WEBLATE_LICENSE_FILTER¶: Configura LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED¶: Configura LICENSE_REQUIRED

WEBLATE_WEBSITE_REQUIRED¶: Configura WEBSITE_REQUIRED

WEBLATE_HIDE_VERSION¶: Configura HIDE_VERSION..

WEBLATE_BASIC_LANGUAGES¶: Configura BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH¶: Configura DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶: Added in version 4.6.

Configura el limitador de velocidad.

Consejo

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

Ver también

Rate limiting, RATELIMIT_ATTEMPTS, RATELIMIT_WINDOW, RATELIMIT_LOCKOUT

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

Configures API rate limiting. Defaults to 100/day for anonymous and 5000/hour for authenticated users.

Ver también

Limitación de la tasa de API

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

Configura ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

Configura ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

Configura AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

Configura LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

Configura SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

Configures BORG_EXTRA_ARGS as a comma separated list of args.

Ejemplo:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

Configura 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_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_UNUSED_ALERT_DAYS¶: Added in version 4.17.

Configures UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

Allow CORS requests from given origins.

Ejemplo:

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

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

Configures maximal body size accepted by the built-in web server.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Consejo

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Certificados SSL automáticos con Let’s Encrypt.

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 Solicitudes de incorporación de GitHub, but applies to all Integración de control de versiones with appropriately changed variable names.

An example configuration for GitHub 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", } }'

Or the path to a file containing the Python dictionary:

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 Solicitudes de incorporación de GitHub by changing GITHUB_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Configures Solicitudes de fusión de GitLab by changing GITLAB_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Configures Solicitudes de incorporación de Gitea by changing GITEA_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Configures Solicitudes de fusión de Pagure by changing PAGURE_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Configures Bitbucket Server pull requests by changing BITBUCKETSERVER_CREDENTIALS.

Ver también

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 pull requests by changing AZURE_DEVOPS_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

Configuración de las sugerencias automáticas¶

Distinto en la versión 4.13: Los servicios de sugerencias automáticas ahora están configurados en la interfaz de usuario, consulte Sugerencias automáticas.

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

Configuración de autenticación¶

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¶

Configuración de la autenticación con LDAP.

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)

Ver también

Passing secrets, Autenticación LDAP

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¶: Activa la Autenticación por 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 GitHub EE authentication.

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET¶: Activa la Autenticación por Bitbucket.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Activa la OAuth 2 de Facebook.

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¶: Activa la Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Activa la OAuth 2 de GitLab.

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Enables Gitea authentication.

Active Directory de Azure¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Enables Azure Active Directory authentication, see Active Directory de Microsoft Azure.

Azure Active Directory 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 Azure Active Directory authentication with Tenant support, see Active Directory de Microsoft Azure.

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

Proveedores de Linux¶

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¶

SOCIAL_AUTH_SLACK_SECRET¶: Enables Slack authentication, see Slack.

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¶: Configures generic OpenID Connect integration.

Ver también

OIDC (OpenID Connect)

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 Autenticación por SAML.

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

Otras configuraciones de autenticación¶

WEBLATE_NO_EMAIL_AUTH¶: Deshabilita la autenticación de correo electrónico cuando se establece en cualquier valor. Consulte Desactivar la autenticación por contraseña.

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

Puesta en marcha de la base de datos PostgreSQL¶

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

Ver también

Configuración de base de datos para Weblate

POSTGRES_PASSWORD¶: Contraseña de PostgreSQL.

Ver también

Passing secrets

POSTGRES_USER¶: Nombre de usuario de PostgreSQL.

POSTGRES_DB¶: Nombre de base de datos de PostgreSQL.

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 role to alter during migrations, see Configurar Weblate para que utilice PostgreSQL.

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.

Distinto en la versión 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.

Ejemplo de configuración:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Ver también

CONN_MAX_AGE, Persistent connections

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.

Ejemplo de configuración:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Ver también

DISABLE_SERVER_SIDE_CURSORS, Transaction pooling and server-side cursors

WEBLATE_DATABASES¶: Added in version 5.1.

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

MySQL or MariaDB server¶

Neither MySQL nor MariaDB can not be configured via environment variables. See MySQL y MariaDB for info on using those with Weblate. Use WEBLATE_DATABASES to configure the database connection manually.

Configuración de copia de respaldo de la base de datos¶

Ver también

Datos volcados para las copias de respaldo

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

Caching server setup¶

Using Redis is strongly recommended by Weblate and you have to provide a Redis instance when running Weblate in Docker.

Ver también

Enable caching

REDIS_HOST¶: The Redis server hostname or IP address. Defaults to cache.

REDIS_PORT¶: The Redis server port. Defaults to 6379.

REDIS_DB¶: The Redis database number, defaults to 1.

REDIS_PASSWORD¶: La contraseña del servidor Redis, no utilizada de manera predeterminada.

Ver también

Passing secrets

REDIS_TLS¶: Permite el uso de SSL para la conexión con Redis.

REDIS_VERIFY_SSL¶: Se puede utilizar para desactivar la verificación de certificados SSL para la conexión con Redis.

Puesta en funcionamiento del servidor de correo¶

Para que funcione el correo saliente, debe proporcionar un servidor de correo.

Ejemplo de configuración de TLS:

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

Ejemplo de configuración de 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

Ver también

Configurar el correo electrónico saliente

WEBLATE_EMAIL_HOST¶: Nombre de anfitrión o dirección IP del servidor de correo.

Ver también

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, WEBLATE_EMAIL_USE_TLS, EMAIL_HOST

WEBLATE_EMAIL_PORT¶: Puerto del servidor de correo, cuyo valor predeterminado es 25.

Ver también

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: Usuario de autenticación del correo electrónico.

Ver también

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶: Contraseña de autenticación del correo electrónico.

Ver también

Passing secrets, EMAIL_HOST_PASSWORD

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.

Distinto en la versión 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Ver también

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.

Distinto en la versión 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Ver también

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶: Configura el dorsal Django para utilizarlo para enviar mensajes de correo electrónico.

Ver también

Configure e-mail sending, EMAIL_BACKEND

WEBLATE_AUTO_UPDATE¶: Configura si Weblate debe actualizar los repositorios y cómo.

Ver también

AUTO_UPDATE

Nota

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

Integración del sitio¶

WEBLATE_GET_HELP_URL¶: Configura GET_HELP_URL.

WEBLATE_STATUS_URL¶: Configura STATUS_URL.

WEBLATE_LEGAL_URL¶: Configura LEGAL_URL.

WEBLATE_PRIVACY_URL¶: Configura PRIVACY_URL.

Collecting error reports and monitoring performance¶

Se recomienda recopilar sistemáticamente los errores que se producen en la instalación; vea ref:collecting-errors.

Para activar la compatibilidad con Rollbar, defina lo siguiente:

ROLLBAR_KEY¶: Su ficha de acceso POST al servidor de Rollbar.

ROLLBAR_ENVIRONMENT¶: Su entorno de Rollbar, cuyo valor predeterminado es production.

Para activar la compatibilidad con Sentry, defina lo siguiente:

SENTRY_DSN¶: Your Sentry DSN, see SENTRY_DSN.

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

SENTRY_TRACES_SAMPLE_RATE¶

Configure sampling rate for performance monitoring. Set to 1 to trace all events, 0 (the default) disables tracing.

Ejemplo:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

Ver también

Sentry Performance Monitoring,

SENTRY_PROFILES_SAMPLE_RATE¶

Configure sampling rate for profiling monitoring. Set to 1 to trace all events, 0 (the default) disables tracing.

Ejemplo:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

Ver también

Sentry Profiling

SENTRY_SEND_PII¶: Configures SENTRY_SEND_PII.

CDN de regionalización¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

Configuración para CDN de regionalización de JavaScript.

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

Nota

You are responsible for setting up serving of the files generated by Weblate, it only does stores the files in configured location.

Ver también

Traducir HTML y JavaScript mediante la CDN de Weblate, LOCALIZE_CDN_URL, LOCALIZE_CDN_PATH

Cambiar las aplicaciones habilitadas, las comprobaciones, los complementos o las correcciones automáticas¶

La configuración integrada de comprobaciones, complementos o correcciones automáticas habilitadas se puede ajustar mediante las siguientes variables:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

Ejemplo:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

Ver también

CHECK_LIST, AUTOFIX_LIST, WEBLATE_ADDONS, INSTALLED_APPS

Configuración de contenedor¶

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_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, and WEB_WORKERS. You can use these settings to fine-tune.

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

CELERY_BEAT_OPTIONS¶

These variables allow you to adjust Celery worker options. It can be useful to adjust concurrency (--concurrency 16) or use different pool implementation (--pool=gevent).

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

Ejemplo:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Ver también

Celery worker options, Tareas en segundo plano con Celery

WEB_WORKERS¶

Configure how many uWSGI workers should be executed.

It defaults to WEBLATE_WORKERS.

Ejemplo:

environment:
  WEB_WORKERS: 32

WEBLATE_SERVICE¶

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

Se definen los siguientes servicios:

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-celery: Generic Celery worker.
celery-memory: Memoria de traducción para programadores en Celery.
celery-notify: Notificaciones para programadores de Celery.
celery-translate: Traducción automática para programadored en Celey.
web: Servidor web.

Volúmenes de contenedores Docker¶

There are two volumes (data and cache) exported by the Weblate container. The other service containers (PostgreSQL or Redis) have their data volumes as well, but those are not covered by this document.

The data volume is used to store Weblate persistent data such as cloned repositories or to customize Weblate installation.

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). In the container it is mounted as /app/data.

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.

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

Ver también

Docker volumes documentation

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.

Ver también

Personalizar 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 Crear un módulo Python, 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 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 Volúmenes de contenedores Docker). For example creating /app/data/python/customize/static/favicon.ico will replace the favicon.

Consejo

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 Información legal documents can be placed into /app/data/python/customize/templates/legal/documents.

Alternatively you can also include own module (see Personalizar 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

Configuración del servidor PostgreSQL¶

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

There are individual services for each Celery queue (see Tareas en segundo plano con Celery for details). You can stop processing some tasks by stopping the appropriate worker:

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