Installing using Docker

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

Hardware requirements

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

  • 3 GB of RAM

  • 2 CPU cores

  • 1 GB of storage space

Note

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

Memory usage

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

Hint

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

CPU usage

Many concurrent users increase the amount of needed CPU cores.

Storage usage

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

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

Nodes

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 Database setup for Weblate).

Installation

Hint

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

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

  1. Clone the weblate-docker repo:

    git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
    cd weblate-docker
    
  2. 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
    

    Note

    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.

  3. Start Weblate containers:

    docker compose up
    

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

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

<MAJOR>

Weblate stable release

Rolling updates within a major version in a production environment

<MAJOR>.<MINOR>

Weblate stable release

Rolling updates within a minor version in a production environment

<VERSION>.<PATCH>

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

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

Docker container with HTTPS support

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

Using own SSL certificates

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

  • ssl/fullchain.pem containing the certificate including any needed CA certificates

  • ssl/privkey.pem containing the private key

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

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

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

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

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

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

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

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

Automatic SSL certificates using Let’s Encrypt

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

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

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

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

Upgrading the Docker container

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

Changed in version 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 Upgrading PostgreSQL container.

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.

Note

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 Upgrading PostgreSQL container for upgrading the PostgreSQL server.

Upgrading PostgreSQL container

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.

  1. Stop Weblate container:

    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. Remove the PostgreSQL volume:

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

    Hint

    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. Restore the database from the backup:

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

    Hint

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

    Hint

    Please check that the database name matches POSTGRES_DB.

  9. Start all remaining containers:

    docker compose up -d
    

Admin sign in

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

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

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

You can also fine-tune individual worker categories:

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

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

environment:
  CELERY_SINGLE_PROCESS: 1

Scaling horizontally

Added in version 4.6.

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

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

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

Docker environment variables

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

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

Generic settings

WEBLATE_DEBUG

Configures Django debug mode using DEBUG.

Example:

environment:
  WEBLATE_DEBUG: 1
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

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

WEBLATE_SITE_DOMAIN

Configures the site domain. This parameter is required.

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

Example:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com
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.

Warning

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.

WEBLATE_ADMIN_NOTIFY_ERROR

Whether to sent 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.

WEBLATE_SERVER_EMAIL

The email address that error messages are sent from.

WEBLATE_DEFAULT_FROM_EMAIL

Configures the address for outgoing e-mails.

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.

Example:

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

Configures whether registrations are open by toggling REGISTRATION_OPEN.

Example:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
WEBLATE_REGISTRATION_ALLOW_BACKENDS

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

Example:

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

Configures the used time zone in Weblate, see TIME_ZONE.

Note

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

Example:

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.

Hint

Please see ENABLE_HTTPS documentation for possible caveats.

Note

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

Example:

environment:
  WEBLATE_ENABLE_HTTPS: 1
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.

WEBLATE_IP_PROXY_HEADER

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

Enables IP_BEHIND_REVERSE_PROXY and sets IP_PROXY_HEADER.

Note

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

  • converts all characters to uppercase

  • replaces any hyphens with underscores

  • prepends HTTP_ prefix

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

Example:

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.

Note

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.

Example:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https
WEBLATE_REQUIRE_LOGIN

Enables REQUIRE_LOGIN to enforce authentication on whole Weblate.

Example:

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

WEBLATE_SIMPLIFY_LANGUAGES

Configures the language simplification policy, see SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL

Configures the default Access control for new projects, see DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT

Configures the default value for Restricted access for new components, see DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION

Configures the default value for Allow translation propagation for new components, see DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL

Configures DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME

Configures DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM

Configures DEFAULT_SHARED_TM.

WEBLATE_AKISMET_API_KEY

Configures the Akismet API key, see AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY

Configures GPG signing of commits, see WEBLATE_GPG_IDENTITY.

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
WEBLATE_CSP_FORM_SRC

Allows to customize Content-Security-Policy HTTP header.

WEBLATE_LICENSE_FILTER

Configures LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Configures LICENSE_REQUIRED

WEBLATE_WEBSITE_REQUIRED

Configures WEBSITE_REQUIRED

WEBLATE_HIDE_VERSION

Configures HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES

Configures BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH

Configures DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS
WEBLATE_RATELIMIT_LOCKOUT
WEBLATE_RATELIMIT_WINDOW

Added in version 4.6.

Configures rate limiter.

Hint

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

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.

WEBLATE_ENABLE_HOOKS

Added in version 4.13.

Configures ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS

Added in version 4.6.1.

Configures ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX

Added in version 4.15.

Configures AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH

Added in version 4.9.

Configures LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS

Added in version 4.9.

Configures SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS

Added in version 4.9.

Configures BORG_EXTRA_ARGS as a comma separated list of args.

Example:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
WEBLATE_ENABLE_SHARING

Added in version 4.14.1.

Configures ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK

Added in version 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD

Added in version 4.15.

Configures EXTRA_HTML_HEAD.

WEBLATE_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 to API from given origins.

Example:

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

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

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

Hint

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Automatic SSL certificates using 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 GitHub pull requests, but applies to all Version control integration 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 GitHub pull requests by changing GITHUB_CREDENTIALS.

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST
WEBLATE_GITLAB_CREDENTIALS

Configures GitLab merge requests by changing GITLAB_CREDENTIALS.

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Configures Gitea pull requests by changing GITEA_CREDENTIALS.

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Configures Pagure merge requests by changing PAGURE_CREDENTIALS.

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Configures Bitbucket Server pull requests by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME
WEBLATE_BITBUCKETCLOUD_WORKSPACE
WEBLATE_BITBUCKETCLOUD_TOKEN
WEBLATE_BITBUCKETCLOUD_HOST
WEBLATE_BITBUCKETCLOUD_CREDENTIALS

Configures Bitbucket Cloud pull requests by changing BITBUCKETCLOUD_CREDENTIALS.

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.

Automatic suggestion settings

Changed in version 4.13: Automatic suggestion services are now configured in the user interface, see Automatic suggestions.

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

Authentication settings

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

LDAP authentication configuration.

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)

GitHub

WEBLATE_SOCIAL_AUTH_GITHUB_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME
WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET
WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID

Enables GitHub authentication.

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

Enables Bitbucket authentication.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY
WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET

Enables Facebook OAuth 2.

Google

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS
WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS

Enables Google OAuth 2.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL

Enables GitLab OAuth 2.

Gitea

WEBLATE_SOCIAL_AUTH_GITEA_API_URL
WEBLATE_SOCIAL_AUTH_GITEA_KEY
WEBLATE_SOCIAL_AUTH_GITEA_SECRET

Enables Gitea authentication.

Azure Active Directory

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET

Enables Azure Active Directory authentication, see Microsoft Azure Active Directory.

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 Microsoft Azure Active Directory.

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.

Linux vendors

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.

SAML

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

WEBLATE_SAML_IDP_ENTITY_ID
WEBLATE_SAML_IDP_URL
WEBLATE_SAML_IDP_X509CERT
WEBLATE_SAML_IDP_IMAGE
WEBLATE_SAML_IDP_TITLE

SAML Identity Provider settings, see SAML authentication.

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.

Other authentication settings

WEBLATE_NO_EMAIL_AUTH

Disables e-mail authentication when set to any value. See Turning off password authentication.

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.

PostgreSQL database setup

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

POSTGRES_PASSWORD

PostgreSQL password.

See also

Passing secrets

POSTGRES_USER

PostgreSQL username.

POSTGRES_DB

PostgreSQL database name.

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 Configuring Weblate to use 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.

Changed in 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.

Example configuration:

environment:
    POSTGRES_CONN_MAX_AGE: 3600
POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Added in version 4.9.1.

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

Example configuration:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1
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 and MariaDB for info on using those with Weblate. Use WEBLATE_DATABASES to configure the database connection manually.

Database backup settings

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.

See also

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

The Redis server password, not used by default.

See also

Passing secrets

REDIS_TLS

Enables using SSL for Redis connection.

REDIS_VERIFY_SSL

Can be used to disable SSL certificate verification for Redis connection.

Email server setup

To make outgoing e-mail work, you need to provide a mail server.

Example TLS configuration:

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

Example SSL configuration:

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
WEBLATE_EMAIL_HOST

Mail server hostname or IP address.

WEBLATE_EMAIL_PORT

Mail server port, defaults to 25.

See also

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER

E-mail authentication user.

See also

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD

E-mail authentication 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.

Changed in version 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

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.

Changed in version 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

WEBLATE_EMAIL_BACKEND

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

WEBLATE_AUTO_UPDATE

Configures if and how Weblate should update repositories.

See also

AUTO_UPDATE

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.

Collecting error reports and monitoring performance

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

To enable support for Rollbar, set the following:

ROLLBAR_KEY

Your Rollbar post server access token.

ROLLBAR_ENVIRONMENT

Your Rollbar environment, defaults to production.

To enable support for Sentry, set following:

SENTRY_DSN

Your Sentry DSN, see SENTRY_DSN.

SENTRY_ENVIRONMENT

Your Sentry Environment (optional), defaults to WEBLATE_SITE_DOMAIN.

SENTRY_TRACES_SAMPLE_RATE

Configures SENTRY_TRACES_SAMPLE_RATE.

Example:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5
SENTRY_PROFILES_SAMPLE_RATE

Configures SENTRY_PROFILES_SAMPLE_RATE.

Example:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5
SENTRY_SEND_PII

Configures SENTRY_SEND_PII.

Localization CDN

WEBLATE_LOCALIZE_CDN_URL
WEBLATE_LOCALIZE_CDN_PATH

Added in version 4.2.1.

Configuration for JavaScript localization 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 does stores the files in configured location.

Changing enabled apps, checks, add-ons, machine translation or autofixes

The built-in configuration of enabled checks, add-ons 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_ADDONS
WEBLATE_REMOVE_ADDONS
WEBLATE_ADD_MACHINERY

Added in version 5.6.1.

WEBLATE_REMOVE_MACHINERY

Added in version 5.6.1.

Example:

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

Container settings

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.

Example:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16
CELERY_SINGLE_PROCESS

Added in version 5.7.1: This variable can be set to 1 to run only one celery process. This reduces memory usage but may impact Weblate performance.

environment:
  CELERY_SINGLE_PROCESS: 1
WEB_WORKERS

Configure how many uWSGI workers should be executed.

It defaults to WEBLATE_WORKERS.

Example:

environment:
  WEB_WORKERS: 32
WEBLATE_SERVICE

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

Following services are defined:

celery-beat

Celery task scheduler, only one instance should be running. This container is also responsible for the database structure migrations and it should be started prior others.

celery-backup

Celery worker for backups, only one instance should be running.

celery-celery

Generic Celery worker.

celery-memory

Translation memory Celery worker.

celery-notify

Notifications Celery worker.

celery-translate

Automatic translation Celery worker.

web

Web server.

Docker container volumes

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

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

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.

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 Creating a Python module, you could create a file at weblate_customization/weblate_customization/settings.py with the following initial code:

    from weblate.settings_docker import *
    
  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 /app/venv/bin/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.

Replacing logo and other static files

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

Hint

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

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

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

Configuring PostgreSQL server

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

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

Container internals

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

To check the services status use:

docker compose exec --user weblate weblate supervisorctl status

There are individual services for each Celery queue (see Background tasks using Celery for details). You can stop processing some tasks by stopping the appropriate worker:

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