Instalando usando Docker

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

Requisitos de hardware

O Weblate deve funcionar em qualquer hardware contemporâneo sem problemas. A seguir está a configuração mínima necessária para executar o Weblate em um único host (Weblate, banco de dados e servidor web):

  • 3 GB de RAM

  • 2 núcleos de CPU

  • 1 GB de espaço de armazenamento

Nota

Os requisitos reais para a sua instalação do Weblate variam fortemente com base no tamanho das traduções gerenciadas nele.

Memória utilizada

Quanto mais memória, melhor - ela é usada para armazenamento em cache em todos os níveis (sistema de arquivos, banco de dados e Weblate). Para centenas de componentes de tradução, recomenda-se pelo menos 4 GB de RAM.

Dica

Para sistemas com menos memória do que o recomendado, Configuração do Celery de processo único é recomendado.

Uso da CPU

Muitos usuários simultâneos aumentam a quantidade de núcleos de CPU necessários.

Uso de armazenamento

O uso típico de armazenamento de banco de dados é de cerca de 300 MB por 1 milhão de palavras hospedadas.

O espaço de armazenamento necessário para repositórios clonados varia, mas o Weblate tenta manter seu tamanho mínimo fazendo clones rasos.

Nodes

Para sites de pequeno e médio porte (milhões de palavras hospedadas), todos os componentes do Weblate (consulte Visão geral da arquitetura) podem ser executados em um único nó.

Quando você atingir centenas de milhões de palavras hospedadas, é recomendável ter um nó dedicado para o banco de dados (consulte Configuração de banco de dados para o Weblate).

Instalação

Dica

Os exemplos a seguir presumem que você tem um ambiente Docker funcional, com docker-compose-plugin instalado. Verifique a documentação do Docker para obter instruções.

Isso cria um servidor de implantação do Weblate via HTTP, portanto, você deve colocá-lo atrás de um proxy de terminação HTTPS. Você também pode implantar com um proxy HTTPS, consulte Certificados SSL automáticos usando Let’s Encrypt. Para configurações maiores, consulte Dimensionamento horizontal.

  1. Clone o repositório weblate-docker:

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

  2. Crie um arquivo docker-compose.override.yml com suas configurações. Consulte Variáveis de ambiente do Docker para uma lista completa das variáveis de ambiente.

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

    Nota

    Se WEBLATE_ADMIN_PASSWORD não estiver definida, o usuário admin é criado com uma senha aleatória mostrada na primeira inicialização.

    O exemplo fornecido faz o Weblate escutar na porta 80. Edite o mapeamento da porta no arquivo docker-compose.override.yml para alterar isso.

  3. Inicie os contêineres do Weblate:

    docker compose up

Aproveite a implantação do Weblate, ele está acessível na porta 80 do contêiner weblate.

Ver também

Invocando comandos de gerenciamento

Escolhendo o registro de imagem do Docker

Os contêineres do Weblate são publicados nos seguintes registros:

Nota

Todos os exemplos atualmente buscam imagens do Docker Hub, por favor ajuste a configuração para utilizar um registro diferente.

Escolhendo a tag de imagem do Docker

Por favor, escolha uma tag que corresponda ao seu ambiente e expectativas:

Nome da tag

Descrição

Caso de uso

latest

Versão estável do Weblate, corresponde à última versão marcada

Atualizações contínuas em um ambiente de produção

<YEAR>

Versão estável do Weblate

Rolling updates within a calendar year in a production environment

<YEAR>.<MONTH>

Versão estável do Weblate

Rolling updates within a monthly release in a production environment

<YEAR>.<MONTH>.<PATCH>.<BUILD>

Versão estável do Weblate

Implantação bem definida em um ambiente de produção

edge

Lançamento estável do Weblate com alterações de desenvolvimento no contêiner Docker (por exemplo, dependências atualizadas)

Atualizações contínuas em um ambiente de teste

edge-<DATE>-<SHA>

Lançamento estável do Weblate com alterações de desenvolvimento no contêiner Docker (por exemplo, dependências atualizadas)

Implantação bem definida em um ambiente de teste

bleeding

Versão de desenvolvimento do Weblate do Git

Rolling updates to test upcoming Weblate features

bleeding-<DATE>-<SHA>

Versão de desenvolvimento do Weblate do Git

Implantação bem definida para testar os próximos recursos da Weblate

Cada imagem é testada pelo nosso CI antes de ser publicada, então até mesmo a versão bleeding deve ser bastante segura de usar.

A lista completa de tags publicadas pode ser encontrada em GitHub Packages

Contêiner Docker com suporte a HTTPS

Por favor, consulte Instalação para instruções genéricas de implantação, esta seção apenas menciona diferenças em comparação a ela.

SSL terminating proxy

SSL can be terminated outside Weblate container. To make this work well together, several headers need to be passed to the container so that it is aware of its actual environment. In more detail, these headers are described in Executando por trás de um proxy reverso.

Example nginx reverse proxy configuration for a Docker container.
location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 3600s;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
}
Docker container environment for external SSL termination.
WEBLATE_ENABLE_HTTPS=1
WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR

Usando seus próprios certificados SSL

No caso de você ter seu próprio certificado SSL que deseja usar, basta colocar os arquivos no volume de dados Weblate (consulte Volumes de contêiner Docker):

  • ssl/fullchain.pem contendo o certificado, incluindo quaisquer certificados CA necessários

  • ssl/privkey.pem contendo a chave privada

Ambos os arquivos devem pertencer ao mesmo usuário que inicia o contêiner do docker e ter a máscara de arquivo definida como 600 (legível e gravável apenas pelo usuário dono).

Além disso, o contêiner Weblate agora aceitará conexões SSL na porta 4443. Você ainda vai querer incluir o encaminhamento de porta para HTTPS na substituição de composição do docker:

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

Se você já hospeda outros sites no mesmo servidor, é provável que as portas 80 e 443 sejam usadas por um proxy reverso, como NGINX. Para passar a conexão HTTPS do NGINX para o contêiner do docker, você pode usar a seguinte configuração:

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

Substitua <SITE_URL>, <SITE> e <EXPOSED_DOCKER_PORT> por valores reais de seu ambiente.

Certificados SSL automáticos usando Let’s Encrypt

Caso você queira usar certificados SSL Let’s Encrypt gerados automaticamente na instalação pública, você precisa adicionar um proxy HTTPS reverso em um contêiner Docker adicional, https-portal será usado para isso. Isso é usado no arquivo docker-compose-https.yml. Em seguida, crie um arquivo docker-compose-https.override.yml com suas configurações:

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'

Sempre que invocar docker compose, você precisa passar os dois arquivos para ele, e então fazer:

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

Atualizando o contêiner Docker

Normalmente, é uma boa ideia atualizar apenas o contêiner Weblate e manter o contêiner PostgreSQL na versão que você possui, já que atualizar o PostgreSQL é muito doloroso e na maioria dos casos não traz muitos benefícios.

Você pode fazer isso mantendo o docker-compose existente e apenas obter as imagens mais recentes e reiniciar:

# 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

O banco de dados do Weblate deve ser migrado automaticamente na primeira inicialização e não deve haver necessidade de ações manuais adicionais.

Nota

Direct upgrades are only supported for releases from the current or previous calendar year. If you need to upgrade from an older release, upgrade first to an intermediate version listed in Instruções específicas da versão.

Você também pode querer atualizar o repositório docker-compose, embora não seja necessário na maioria dos casos. Consulte Atualizando contêiner PostgreSQL para atualizar o servidor PostgreSQL.

Atualizando contêiner PostgreSQL

Nota

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

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

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

See PGDATA documentation for more information.

Os contêineres PostgreSQL não oferecem suporte a atualização automática entre versões, você precisa realizar a atualização manualmente. Os passos a seguir mostram uma das opções de atualização.

Ver também

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

  1. Pare o contêiner do Weblate:

    docker compose stop weblate cache

  2. Faça backup do banco de dados:

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

  3. Pare o contêiner de banco de dados:

    docker compose stop database

  4. Remova o volume do PostgreSQL:

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

    Dica

    O nome do volume contém o nome do projeto Docker Compose, que por padrão é o nome do diretório, que neste caso é weblate-docker neste documento.

  5. Ajuste o docker-compose.yml para usar a nova versão do PostgreSQL.

  6. Inicie o contêiner de banco de dados:

    docker compose up -d database

  7. Restaure o banco de dados a partir do backup:

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

    Dica

    Verifique se o nome do banco de dados corresponde a POSTGRES_DB.

  8. (Opcional) Atualize a senha do usuário do Weblate. Isso pode ser necessário ao migrar para o PostgreSQL 14 ou 15, pois a forma de armazenar senhas foi alterada:

    docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"

    Dica

    Verifique se o nome do banco de dados corresponde a POSTGRES_DB.

  9. Inicie todos os contêineres restantes:

    docker compose up -d

Autenticação como administrador

Após a configuração do contêiner, você pode entrar como usuário admin com a senha fornecida em WEBLATE_ADMIN_PASSWORD, ou uma senha aleatória gerada na primeira inicialização se não tiver sido definida.

Para redefinir a senha do admin, reinicie o contêiner com WEBLATE_ADMIN_PASSWORD definido com a nova senha.

Ver também

Quantidade total de processos e consumo de memória

O número de processos de trabalho para WSGI e Celery é determinado automaticamente com base no número de CPUs. Isso funciona bem para a maioria das máquinas virtuais em Nuvem, pois normalmente têm poucas CPUs e boa quantidade de memória.

Caso você tenha muitos núcleos de CPU e tenha problemas de memória insuficiente, tente reduzir o número de workers:

environment:
  WEBLATE_WORKERS: 2

Você também pode ajustar as categorias de workers individuais:

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

O uso da memória pode ser reduzido ainda mais com a execução de apenas um único processo do Celery:

environment:
  CELERY_SINGLE_PROCESS: 1

Ver também

Dimensionamento horizontal

Adicionado na versão 4.6.

Você pode executar vários contêineres Weblate para dimensionar o serviço horizontalmente. O volume /app/data deve ser compartilhado por todos os contêineres, é recomendado usar um sistema de arquivos de cluster como o GlusterFS para isso. O volume /app/cache deve ser separado para cada contêiner.

Cada contêiner do Weblate tem uma função definida usando a variável de ambiente WEBLATE_SERVICE. Siga atentamente a documentação, pois alguns dos serviços devem ser executados apenas uma vez no cluster, e a ordem dos serviços também é importante.

Você pode encontrar configuração de exemplo no repositório docker-compose como docker-compose-split.yml.

Variáveis de ambiente do Docker

Many of Weblate’s Configuração can be set in the Docker container using the environment variables described below.

Se você precisar definir uma configuração não exposta por meio de variáveis de ambiente do Docker, consulte Configuração além das variáveis de ambiente.

Passando segredos

Adicionado na versão 5.0.

O contêiner do Weblate suporta a passagem de segredos como arquivos. Para utilizar isso, adicione o sufixo _FILE à variável de ambiente e passe o arquivo secreto via Docker.

Relacionado docker-compose.yml pode ser parecido com:

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 também

Como usar segredos no Docker Compose

Configurações genéricas

WEBLATE_DEBUG

Configura o modo de depuração do Django usando DEBUG.

Exemplo:

environment:
  WEBLATE_DEBUG: 1

Ver também

Desabilitar o modo de depuração

WEBLATE_LOGLEVEL

Configure a verbosidade do registro. Defina como DEBUG para obter logs mais detalhados.

O padrão é INFO quando WEBLATE_DEBUG está desligado, DEBUG é usado quando o modo de depuração está ligado.

Para obter um registro mais silencioso, use ERROR ou WARNING.

WEBLATE_LOGLEVEL_DATABASE

Configura o log da verbosidade das consultas ao banco de dados.

WEBLATE_LOG_GELF_HOST

Adicionado na versão 5.9.

Configura o registro remoto usando conexão GELF TCP. Pode ser usado para integrar com Graylog.

WEBLATE_LOG_GELF_PORT

Adicionado na versão 5.9.

Use porta personalizada para WEBLATE_LOG_GELF_HOST, o padrão é 12201.

WEBLATE_SITE_TITLE

Altera o título do site mostrado no cabeçalho de todas as páginas.

WEBLATE_SITE_DOMAIN

Configura o domínio do site. Este parâmetro é obrigatório.

Inclua um port se estiver usando uma que não seja padrão.

Exemplo:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Ver também

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Configura o nome e o e-mail do administrador do site. É usado para ADMINS e para criar o usuário admin (veja WEBLATE_ADMIN_PASSWORD para mais informações).

Exemplo:

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

Ver também

WEBLATE_ADMIN_PASSWORD

Define a senha para o usuário admin.

  • Se não for definido e o usuário admin não existir, ele será criado com uma senha aleatória mostrada na primeira inicialização do contêiner.

  • Se não for definido e o usuário admin existir, nenhuma ação será executada.

  • Se definido, o usuário admin é ajustado em cada inicialização do contêiner para corresponder a WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME e WEBLATE_ADMIN_EMAIL.

Aviso

Pode ser um risco de segurança armazenar a senha no arquivo de configuração. Considere usar essa variável apenas para configuração inicial (ou deixe o Weblate gerar uma senha aleatória na inicialização) ou para recuperação de senha.

Ver também

WEBLATE_ADMIN_NOTIFY_ERROR

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

Talvez você queira usar outra coleta de erros, como Sentry ou Rollbar, e desativar essa opção.

Ver também

WEBLATE_SERVER_EMAIL

O endereço de e-mail a partir do qual mensagens de erro são enviadas.

Ver também

WEBLATE_DEFAULT_FROM_EMAIL

Configura o endereço para e-mails de saída.

Ver também

WEBLATE_ADMINS_CONTACT

Configura ADMINS_CONTACT.

WEBLATE_CONTACT_FORM

Configura o comportamento do formulário de contato, veja CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS

Configura os nomes de host HTTP permitidos usando ALLOWED_HOSTS.

O padrão é * que permite todos os nomes de host.

Exemplo:

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

Ver também

WEBLATE_REGISTRATION_OPEN

Configura se os registros são abertos alternando REGISTRATION_OPEN.

Exemplo:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
WEBLATE_REGISTRATION_CAPTCHA

Adicionado na versão 5.10.

Configura se o captcha é usado para registro e outras ações não autenticadas, consulte REGISTRATION_CAPTCHA.

Exemplo:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0
WEBLATE_REGISTRATION_ALLOW_BACKENDS

Configura quais métodos de autenticação podem ser usados para criar uma nova conta via REGISTRATION_ALLOW_BACKENDS.

Exemplo:

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

Adicionado na versão 4.16.

Configurações REGISTRATION_REBIND.

WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS

Adicionado na versão 5.16.1.

Configures REGISTRATION_ALLOW_DISPOSABLE_EMAILS.

Exemplo:

environment:
  WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS: 1
WEBLATE_PROJECT_WEB_RESTRICT_PRIVATE

Adicionado na versão 5.17.

Configures PROJECT_WEB_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_PROJECT_WEB_RESTRICT_ALLOWLIST

Adicionado na versão 5.17.

Configures PROJECT_WEB_RESTRICT_ALLOWLIST.

Expects a comma-separated list of trusted project slugs.

WEBLATE_WEBHOOK_RESTRICT_PRIVATE

Adicionado na versão 5.17.

Configures WEBHOOK_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_WEBHOOK_PRIVATE_ALLOWLIST

Adicionado na versão 5.17.

Configures WEBHOOK_PRIVATE_ALLOWLIST.

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

WEBLATE_ASSET_RESTRICT_PRIVATE

Adicionado na versão 2025.5.

Configures ASSET_RESTRICT_PRIVATE.

Defaults to enabled.

WEBLATE_ASSET_PRIVATE_ALLOWLIST

Adicionado na versão 2025.5.

Configures ASSET_PRIVATE_ALLOWLIST.

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

WEBLATE_TIME_ZONE

Configura o fuso horário usado no Weblate, veja TIME_ZONE.

Nota

Para alterar o fuso horário do próprio contêiner do Docker, use a variável de ambiente TZ.

Exemplo:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague
WEBLATE_ENABLE_HTTPS

Faz com que o Weblate presuma que é operado por trás de um proxy HTTPS reverso, faz com que o Weblate use HTTPS em e-mail e links de API ou defina marcadores seguros em cookies.

Dica

Por favor, consulte a documentação de ENABLE_HTTPS para possíveis advertências.

Nota

Isso não faz com que o contêiner Weblate aceite conexões HTTPS, você precisa configurar isso também, consulte Contêiner Docker com suporte a HTTPS para exemplos.

Exemplo:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Ver também

WEBLATE_NGINX_IPV6

Adicionado na versão 5.17.

Controls whether the bundled NGINX listens on IPv6 addresses.

Supported values are:

  • auto to enable IPv6 listeners only when IPv6 is available in the container runtime. This is the default.

  • on to always enable IPv6 listeners.

  • off to disable IPv6 listeners.

Exemplo:

environment:
  WEBLATE_NGINX_IPV6: auto
WEBLATE_IP_PROXY_HEADER

Permite que o Weblate obtenha o endereço IP de qualquer cabeçalho HTTP fornecido. Use isso ao usar um proxy reverso na frente do contêiner Weblate.

Habilita IP_BEHIND_REVERSE_PROXY e define IP_PROXY_HEADER.

Nota

O formato deve estar de acordo com as expectativas do Django. O Django transforma nomes de cabeçalho HTTP brutos da seguinte forma:

  • converte todos os caracteres em maiúsculas

  • substitui todos os hifenes por sublinhados

  • prefixa o prefixo HTTP_

Portanto, X-Forwarded-For seria mapeado para HTTP_X_FORWARDED_FOR.

Exemplo:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
WEBLATE_IP_PROXY_OFFSET

Adicionado na versão 5.0.1.

Configura IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT

Adicionado na versão 5.0.1.

Um booleano que especifica se deve ser usado o cabeçalho X-Forwarded-Port em vez da variável SERVER_PORT META. Isso só deve ser habilitado se um proxy que define esse cabeçalho estiver em uso.

Ver também

USE_X_FORWARDED_PORT

Nota

Esta é uma configuração Booleana (use "true" ou "false").

WEBLATE_SECURE_PROXY_SSL_HEADER

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

Exemplo:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Ver também

WEBLATE_REQUIRE_LOGIN

Habilita REQUIRE_LOGIN para impor autenticação em todo o Weblate.

Exemplo:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

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

Supported values are:

  • tos-confirm to enable the legal module and enforce terms of service confirmation during social authentication and for signed-in users.

  • wllegal to enable the same integration and additionally load the hosted legal document templates from wllegal. These templates are used by services operated by Weblate s.r.o. and are not intended for general use.

To provide your own legal documents in Docker, override the templates in /app/data/python/customize/templates/legal/documents, see Substituindo o logotipo e outros arquivos estáticos.

Exemplo:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm

Ver também

WEBLATE_PUBLIC_ENGAGE

Enables PUBLIC_ENGAGE.

WEBLATE_GOOGLE_ANALYTICS_ID

Configura o ID para o Google Analytics alterando GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE

Configura o título e a mensagem padrão para pull requests via API alterando DEFAULT_PULL_MESSAGE.

Ver também

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES

Configura a política de simplificação de idioma, veja SIMPLIFY_LANGUAGES.

WEBLATE_HIDE_SHARED_GLOSSARY_COMPONENTS

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

WEBLATE_DEFAULT_ACCESS_CONTROL

Configura o padrão Controle de acesso para novos projetos, veja DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_TRANSLATION_REVIEW

Adicionado na versão 5.16.

Configures the default value for Habilitar revisões, turned off by default.

WEBLATE_DEFAULT_SOURCE_REVIEW

Adicionado na versão 5.16.

Configures the default value for Habilitar revisões de fontes, turned off by default.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT

Configura o valor padrão para Acesso restrito para novos componentes, veja DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION

Configura o valor padrão para Permitir propagação de tradução para novos componentes, veja 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_DEFAULT_AUTOCLEAN_TM

Configures DEFAULT_AUTOCLEAN_TM.

WEBLATE_COMMIT_PENDING_HOURS

Configures the default value for Idade das alterações para fazer commit for new components, see COMMIT_PENDING_HOURS.

WEBLATE_GPG_IDENTITY

Configura a assinatura GPG de commits, veja WEBLATE_GPG_IDENTITY.

Ver também

Assinando commits do Git com GnuPG

WEBLATE_URL_PREFIX

Configura o prefixo da URL onde o Weblate está sendo executado, veja URL_PREFIX.

WEBLATE_STATIC_URL

Configures URL prefix for static files served from CACHE_DIR.

WEBLATE_SILENCED_SYSTEM_CHECKS

Configura verificações que você não deseja que sejam mostradas, veja 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

Permite personalizar o cabeçalho HTTP Content-Security-Policy.

Ver também

WEBLATE_LICENSE_FILTER

Configura LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Configura LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED

Configura WEBSITE_REQUIRED.

WEBLATE_VERSION_DISPLAY

Configures VERSION_DISPLAY.

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

Adicionado na versão 4.6.

Configura o limitador de taxa.

Dica

Você pode definir a configuração para qualquer escopo do limitador de taxa. Para fazer isso, adicione o prefixo WEBLATE_ a qualquer uma das configurações descritas em Limitação de taxa.

Ver também

WEBLATE_API_RATELIMIT_ANON
WEBLATE_API_RATELIMIT_USER

Adicionado na versão 4.11.

Configura a limitação de taxa da API. O padrão é 100/day para usuários anônimos e 5000/hour para usuários autenticados.

Ver também

Limitação de taxa da API

WEBLATE_ENABLE_HOOKS

Adicionado na versão 4.13.

Configura ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS

Adicionado na versão 4.6.1.

Configura ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX

Adicionado na versão 4.15.

Configura AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH

Adicionado na versão 4.9.

Configura LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS

Adicionado na versão 4.9.

Configura SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS

Adicionado na versão 4.9.

Configura BORG_EXTRA_ARGS como uma lista de argumentos separados por vírgula.

Exemplo:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
WEBLATE_ENABLE_SHARING

Adicionado na versão 4.14.1.

Configura ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK

Adicionado na versão 5.5.

Configura SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD

Adicionado na versão 4.15.

Configura EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE

Adicionado na versão 4.15.

Configura PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN

Adicionado na versão 4.15.

Configura PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE

Adicionado na versão 5.16.

Configures PRIVATE_COMMIT_NAME_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN

Adicionado na versão 5.16.

Configures PRIVATE_COMMIT_NAME_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS

Adicionado na versão 4.17.

Configura UNUSED_ALERT_DAYS.

WEBLATE_UPDATE_LANGUAGES

Adicionado na versão 4.3.2.

Configura UPDATE_LANGUAGES.

WEBLATE_VCS_ALLOW_HOSTS

Adicionado na versão 5.15.

Configures VCS_ALLOW_HOSTS.

WEBLATE_VCS_ALLOW_SCHEMES

Adicionado na versão 5.15.

Configures VCS_ALLOW_SCHEMES.

WEBLATE_VCS_RESTRICT_PRIVATE

Adicionado na versão 5.17.

Configures VCS_RESTRICT_PRIVATE.

WEBLATE_VCS_CLONE_DEPTH

Adicionado na versão 5.4.

Configures VCS_CLONE_DEPTH.

WEBLATE_VCS_API_DELAY

Adicionado na versão 5.4.

Configures VCS_API_DELAY.

WEBLATE_VCS_API_TIMEOUT

Adicionado na versão 5.15.

Configures VCS_API_TIMEOUT.

WEBLATE_CORS_ALLOWED_ORIGINS

Adicionado na versão 4.16.

Permite solicitações CORS para API de determinadas origens.

Exemplo:

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

Adicionado na versão 5.6.1: Permite solicitações CORS para API de todas as origens.

WEBLATE_WEBSITE_ALERTS_ENABLED

Adicionado na versão 5.17.

Configures WEBSITE_ALERTS_ENABLED.

CLIENT_MAX_BODY_SIZE

Adicionado na versão 4.16.3.

Configura o tamanho máximo do corpo aceito pelo servidor da Web embutido.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Dica

Essa variável não tem intencionalmente o prefixo WEBLATE_, pois é compartilhada com um contêiner de terceiros usado no Certificados SSL automáticos usando Let’s Encrypt.

WEBLATE_TRANSLATION_UPLOAD_MAX_SIZE

Configures TRANSLATION_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_COMPONENT_ZIP_UPLOAD_MAX_SIZE

Configures COMPONENT_ZIP_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_UPLOAD_MAX_SIZE

Configures PROJECT_BACKUP_UPLOAD_MAX_SIZE.

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

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_MEMBERS

Adicionado na versão 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_MEMBERS.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE

Adicionado na versão 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE

Adicionado na versão 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE

Adicionado na versão 2026.5.

Configures PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO

Adicionado na versão 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

Credenciais de sites de hospedagem de código

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 Pull requests do GitHub, but apply to all Integração com controle de versão with appropriately changed variable names.

Importante

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

An example configuration for GitHub pull requests might look like:

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

Será usado como:

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

Alternativamente, o dicionário Python pode ser fornecido como um texto:

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

Ou o caminho para um arquivo que contém o dicionário Python:

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

Configures Pull requests do GitHub by changing GITHUB_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST
WEBLATE_GITLAB_CREDENTIALS

Configures Merge requests do GitLab by changing GITLAB_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Configures Pull requests do Gitea by changing GITEA_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Configures Merge requests do Pagure by changing PAGURE_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Configures Pull requests do Bitbucket Data Center by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME
WEBLATE_BITBUCKETCLOUD_WORKSPACE
WEBLATE_BITBUCKETCLOUD_TOKEN
WEBLATE_BITBUCKETCLOUD_HOST
WEBLATE_BITBUCKETCLOUD_CREDENTIALS

Configures Pull requests do Bitbucket Cloud by changing BITBUCKETCLOUD_CREDENTIALS.

Ver também

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 Pull requests do Azure DevOps by changing AZURE_DEVOPS_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

Configurações de sugestões automáticas

Alterado na versão 4.13: Serviços de sugestões automáticas agora são configurados na interface de usuário, consulte Sugestões automáticas.

As variáveis de ambiente atuais são importadas durante a migração para o Weblate 4.13, mas alterá-las não surtirá nenhum efeito.

Configurações de autenticação

Dica

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

LDAP

WEBLATE_AUTH_LDAP_SERVER_URI
WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE
WEBLATE_AUTH_LDAP_USER_ATTR_MAP
WEBLATE_AUTH_LDAP_BIND_DN
WEBLATE_AUTH_LDAP_BIND_PASSWORD
WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS
WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER
WEBLATE_AUTH_LDAP_USER_SEARCH_UNION
WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER

Configuração de autenticação LDAP.

Exemplo para vinculação direta:

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

Exemplo para busca e vinculação:

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

Exemplo para vinculação e busca de união:

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

Exemplo como buscar e vincular ao 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 também

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

Habilita Autenticação 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

Habilita Autenticação por GitHub EE.

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET

Habilita Autenticação por Bitbucket.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY
WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET

Habilita OAuth 2 do 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

Habilita Google OAuth 2.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL

Habilita OAuth 2 do GitLab.

Gitea

WEBLATE_SOCIAL_AUTH_GITEA_API_URL
WEBLATE_SOCIAL_AUTH_GITEA_KEY
WEBLATE_SOCIAL_AUTH_GITEA_SECRET

Habilita autenticação por Gitea.

Microsoft Entra ID

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET

Enables Microsoft Entra ID authentication, see Microsoft Entra ID.

Microsoft Entra ID with Tenant support

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID

Enables Microsoft Entra ID authentication with Tenant support, see Microsoft Entra ID.

Keycloak

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY
WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET
WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY
WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM
WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL
WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL
WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE
WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE

Habilita a autenticação Keycloak, veja Keycloak - Open Source Red Hat SSO.

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ID_KEY

Adicionado na versão 5.17.

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

Dica

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

Example when Keycloak is passing authentication to Microsoft.
environment:
  WEBLATE_CSP_FORM_SRC: login.microsoftonline.com

Fornecedores Linux

Você pode habilitar a autenticação usando serviços de autenticação de fornecedores Linux, definindo as seguintes variáveis para qualquer valor.

WEBLATE_SOCIAL_AUTH_FEDORA
WEBLATE_SOCIAL_AUTH_OPENSUSE
WEBLATE_SOCIAL_AUTH_OPENINFRA
WEBLATE_SOCIAL_AUTH_UBUNTU

Slack

WEBLATE_SOCIAL_AUTH_SLACK_KEY
WEBLATE_SOCIAL_AUTH_SLACK_SECRET

Habilita a autenticação Slack, consulte Slack.

OpenID Connect

Adicionado na versão 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT
WEBLATE_SOCIAL_AUTH_OIDC_KEY
WEBLATE_SOCIAL_AUTH_OIDC_SECRET
WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY
WEBLATE_SOCIAL_AUTH_OIDC_TITLE
WEBLATE_SOCIAL_AUTH_OIDC_IMAGE

Configura a integração genérica do OpenID Connect.

Ver também

OIDC (OpenID Connect)

Fedora OpenID Connect

Adicionado na versão 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY
WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET

Configures Fedora OpenID Connect integration.

Ver também

Fedora

SAML

Chaves SAML autoassinadas são geradas automaticamente na primeira inicialização do contêiner. Caso você queira usar chaves próprias, coloque o certificado e a chave privada em /app/data/ssl/saml.crt e /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

Configurações do provedor de identidade SAML, consulte Autenticação por SAML.

WEBLATE_SAML_ID_ATTR_FULL_NAME
WEBLATE_SAML_ID_ATTR_FIRST_NAME
WEBLATE_SAML_ID_ATTR_LAST_NAME
WEBLATE_SAML_ID_ATTR_USERNAME
WEBLATE_SAML_ID_ATTR_EMAIL
WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID

Adicionado na versão 4.18.

Mapeamento de atributos SAML.

Outras configurações de autenticação

WEBLATE_NO_EMAIL_AUTH

Desabilita autenticação por e-mail quando definido com algum valor. Consulte Desativando autenticação por senha.

WEBLATE_MIN_PASSWORD_SCORE

Pontuação mínima da senha conforme avaliada pelo estimador de força de senha zxcvbn. O padrão é 3, defina como 0 para desabilitar a verificação de força da senha.

Ver também

Configuração de banco de dados PostgreSQL

O banco de dados é criado por docker-compose.yml, então essas configurações afetam os contêineres Weblate e PostgreSQL.

Ver também

Configuração de banco de dados para o Weblate

POSTGRES_PASSWORD

Senha do PostgreSQL.

Ver também

Passando segredos

POSTGRES_USER

Nome de usuário do PostgreSQL.

POSTGRES_DB

Nome do banco de dados PostgreSQL.

POSTGRES_HOST

Nome de host ou endereço IP do servidor PostgreSQL. O padrão é database.

POSTGRES_PORT

Porta do servidor PostgreSQL. O padrão é nenhum (usa o valor padrão).

POSTGRES_SSL_MODE

Configura como o PostgreSQL lida com SSL em conexão com o servidor, para as opções possíveis, consulte SSL Mode Descriptions.

POSTGRES_ALTER_ROLE

Configura o nome da função PostgreSQL para alterar durante a migração de banco de dados, consulte Configurando Weblate para usar PostgreSQL.

O padrão é POSTGRES_USER.

POSTGRES_CONN_MAX_AGE

Adicionado na versão 4.8.1.

O tempo de vida de uma conexão de banco de dados, como um número inteiro de segundos. Use 0 para fechar as conexões do banco de dados no final de cada requisição.

Alterado na versão 5.1: O comportamento padrão é ter conexões de banco de dados persistentes ilimitadas.

Habilitar a persistência da conexão normalmente causará uma conexão mais aberta com o banco de dados. Por favor, ajuste sua configuração do banco de dados antes de habilitar.

Exemplo de configuração:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Ver também

POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Adicionado na versão 4.9.1.

Desabilita os cursores do lado do servidor no banco de dados. Isso é necessário em algumas configurações do pgbouncer.

Exemplo de configuração:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Ver também

WEBLATE_DATABASES

Adicionado na versão 5.1.

Set to false to disable environment based configuration of the database connection. Use Substituindo as configurações do volume de dados to configure the database connection manually.

Configurações de backup de banco de dados

Ver também

Dados despejados para os backups

WEBLATE_DATABASE_BACKUP

Configura o despejo diário do banco de dados usando DATABASE_BACKUP. O padrão é plain.

Datastore server setup

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

Ver também

Configure cache

REDIS_HOST

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

REDIS_PORT

The datastore server port. Defaults to 6379.

REDIS_DB

The datastore database number, defaults to 1.

REDIS_USER

Adicionado na versão 5.13: The datastore database user, not used by default.

REDIS_PASSWORD

The datastore server password, not used by default.

Ver também

Passando segredos

REDIS_TLS

Enables using SSL for the datastore connection.

REDIS_VERIFY_SSL

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

Configuração do servidor de e-mail

Para fazer com que o e-mail de saída funcione, você precisa fornecer um servidor de e-mail.

Exemplo de configuração TLS:

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

Exemplo de configuração 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 também

Configuração de e-mail de saída

WEBLATE_EMAIL_HOST

Nome de host ou endereço IP do servidor de correio.

Ver também

WEBLATE_EMAIL_PORT

Porta do servidor de correio, o padrão é 25.

Ver também

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER

Usuário da autenticação por e-mail.

Ver também

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD

Senha da autenticação por e-mail.

Ver também

WEBLATE_EMAIL_USE_SSL

Se deve usar uma conexão TLS (segura) implícita ao falar com o servidor SMTP. Na maioria das documentações de e-mail, esse tipo de conexão TLS é conhecido como SSL. Geralmente é usado na porta 465. Se você estiver tendo problemas, consulte a configuração TLS explícita WEBLATE_EMAIL_USE_TLS.

Alterado na versão 4.11: O suporte a SSL/TLS é habilitado automaticamente com base em WEBLATE_EMAIL_PORT.

Ver também

WEBLATE_EMAIL_USE_TLS

Se deve usar uma conexão TLS (segura) ao falar com o servidor SMTP. Isso é usado para conexões TLS explícitas, geralmente na porta 587 ou 25. Se você estiver tendo conexões travadas, consulte a configuração TLS implícita WEBLATE_EMAIL_USE_SSL.

Alterado na versão 4.11: O suporte a SSL/TLS é habilitado automaticamente com base em WEBLATE_EMAIL_PORT.

Ver também

WEBLATE_EMAIL_BACKEND

Configura o back-end do Django para usar no envio de e-mails.

Ver também

WEBLATE_AUTO_UPDATE

Configura se e como o Weblate deve atualizar os repositórios.

Ver também

AUTO_UPDATE

Nota

Esta é uma configuração booleana (use "true" ou "false").

Integração do site

WEBLATE_GET_HELP_URL

Configura GET_HELP_URL.

WEBLATE_STATUS_URL

Configura STATUS_URL.

Configura LEGAL_URL.

WEBLATE_PRIVACY_URL

Configura PRIVACY_URL.

WEBLATE_PASSWORD_RESET_URL

Configures PASSWORD_RESET_URL.

Coletando relatórios de erros e monitoramento do desempenho

É recomendado coletar erros da instalação sistematicamente, consulte Coletando relatórios de erros e monitoramento do desempenho.

Para habilitar o suporte para Rollbar, defina o seguinte:

ROLLBAR_KEY

Seu token de acesso ao servidor de postagem Rollbar.

ROLLBAR_ENVIRONMENT

Seu ambiente Rollbar, o padrão é production.

Para habilitar o suporte para Sentry, defina o seguinte:

SENTRY_DSN

Seu Sentry DSN, consulte SENTRY_DSN.

SENTRY_ENVIRONMENT

Seu Ambiente de Sentry (opcional), padrão para WEBLATE_SITE_DOMAIN.

SENTRY_MONITOR_BEAT_TASKS

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

SENTRY_TRACES_SAMPLE_RATE

Configura SENTRY_TRACES_SAMPLE_RATE.

Exemplo:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5
SENTRY_PROFILES_SAMPLE_RATE

Configura SENTRY_PROFILES_SAMPLE_RATE.

Exemplo:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5
SENTRY_SEND_PII

Configura SENTRY_SEND_PII.

CDN de localização

WEBLATE_LOCALIZE_CDN_URL
WEBLATE_LOCALIZE_CDN_PATH

Adicionado na versão 4.2.1.

Configuration for CDN add-ons, including CDN de localização do JavaScript and Translation files CDN.

O WEBLATE_LOCALIZE_CDN_PATH é o caminho dentro do contêiner. Ele deve ser armazenado no volume persistente e não no armazenamento temporário.

Uma das possibilidades é armazenar isso dentro do diretório de dados do Weblate:

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 stores the files in configured location. See CDN de localização for secure serving guidance.

Ver também

Alterando aplicativos, verificações, complementos, tradução automática, ou correções automáticas habilitados

A configuração embutida de verificações, complementos ou correções automática habilitados pode ser ajustada pelas seguintes variáveis:

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

Adicionado na versão 5.6.1.

WEBLATE_REMOVE_MACHINERY

Adicionado na versão 5.6.1.

Exemplo:

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

Ver também

Configurações do contêiner

WEBLATE_WORKERS

Adicionado na versão 4.6.1.

Número base de processos de trabalho em execução no contêiner. Quando não definido, é determinado automaticamente na inicialização do contêiner com base no número de núcleos de CPU disponíveis.

É usado para determinar CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS e WEB_WORKERS. Você pode usar essas configurações para fazer o ajuste fino.

CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS

Essas variáveis permitem que você ajuste as opções do worker do Celery. Pode ser útil ajustar a simultaneidade (--concurrency 16) ou usar diferentes implementações de pool (--pool=gevent).

Por padrão, o número de workers simultâneos é baseado em WEBLATE_WORKERS.

Exemplo:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Ver também

CELERY_SINGLE_PROCESS

Adicionado na versão 5.7.1: Essa variável pode ser definida como 1 para executar apenas um processo Celery. Isso reduz o uso de memória, mas pode afetar o desempenho do Weblate.

environment:
  CELERY_SINGLE_PROCESS: 1

Ver também

Configuração do Celery de processo único

WEB_WORKERS

Configura quantos workers WSGI devem ser executados.

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

Exemplo:

environment:
  WEB_WORKERS: 4

Alterado na versão 5.13: WEB_WORKERS configures how many worker processes will used by granian.

WEBLATE_SERVICE

Define quais serviços devem ser executados dentro do contêiner. Use isto para Dimensionamento horizontal.

Os seguintes serviços são definidos:

celery-beat

Agendador de tarefas do Celery, apenas uma instância deve estar em execução. Este contêiner também é responsável pelas migrações da estrutura do banco de dados e deve ser iniciado antes dos demais.

celery-backup

Worker do Celery para backups, apenas uma instância deve estar em execução.

celery-celery

Worker genérico do Celery.

celery-memory

Worker do Celery para memória de tradução.

celery-notify

Worker do Celery para notificações.

celery-translate

Worker do Celery para tradução automática.

web

Servidor web.

Ver também

Background tasks internals

WEBLATE_ANUBIS_URL

Adicionado na versão 5.11.4.

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

Ver também

Volumes de contêiner Docker

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

Nota

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

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

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

O volume data é montado como /app/data` e é utilizado para armazenar dados persistentes do Weblate, como repositórios clonados ou para personalizar a instalação do Weblate. DATA_DIR descreve em mais detalhes o que é armazenado aqui.

The data volume is also place to store Weblate customization such as Substituindo as configurações do volume de dados, Substituindo o logotipo e outros arquivos estáticos or Customizing code.

O posicionamento do volume do Docker no sistema host depende da configuração do Docker, mas geralmente ele é armazenado em /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (o caminho consiste no nome do diretório docker-compose, do contêiner e dos nomes dos volumes).

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

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

tmpfs:
  - /app/cache:exec

When also setting ownership options, keep the exec option:

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

Ao criar os volumes manualmente, os diretórios devem pertencer ao UID 1000, pois é o usuário usado dentro do contêiner.

O contêiner Weblate também pode ser executado com um sistema de arquivos raiz somente leitura. Neste caso, dois volumes tmpfs adicionais devem ser montados: /tmp e /run.

Ver também

Sistema de arquivos raiz somente leitura

Adicionado na versão 4.18.

Ao executar o contêiner com um sistema de arquivos raiz somente leitura, são necessários dois volumes tmpfs adicionais - /tmp e /run.

Configuração além das variáveis de ambiente

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 também

Personalizando o Weblate

Substituindo as configurações do volume de dados

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.

Substituindo as configurações estendendo a imagem do Docker

Para substituir as configurações no nível da imagem do Docker em vez do volume de dados:

  1. Create a custom Python package.

  2. Adicione um módulo ao seu pacote que importe todas as configurações de weblate.settings_docker.

    Por exemplo, dentro da estrutura de pacote de exemplo definida em Criando um módulo Python, você pode criar um arquivo em weblate_customization/weblate_customization/settings.py com o seguinte código inicial:

    from weblate.settings_docker import *

  3. Crie um Dockerfile personalizado que herde da imagem oficial do Weblate Docker e, em seguida, instale seu pacote e aponte a variável de ambiente DJANGO_SETTINGS_MODULE para seu módulo de configurações:

    FROM weblate/weblate

USER root

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

USER 1000

  4. Em vez de usar a imagem Docker oficial do Weblate, construa uma imagem personalizada a partir deste arquivo Dockerfile.

    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.

    Então, ao invés de usar o docker-compose.yml direto do repositório oficial, não modificado, e estendê-lo através do docker-compose .override.yml, você pode querer fazer uma cópia do arquivo docker-compose.yml oficial, e editar sua cópia para substituir image: weblate/weblate por build: ..

    Consulte a Referência de compilação do arquivo Compose para obter detalhes sobre como criar imagens a partir da fonte ao usar docker-compose.

  5. Estenda seu módulo de configurações personalizadas para definir ou redefinir as configurações.

    Você pode definir as configurações antes ou depois da instrução de importação acima para determinar quais configurações têm precedência. As configurações definidas antes da instrução de importação podem ser substituídas por variáveis de ambiente e substituições de configuração definidas no volume de dados. A configuração definida após a instrução de importação não pode ser substituída.

    Você também pode ir mais longe. Por exemplo, você pode reproduzir algumas das coisas que weblate.docker_settings faz, como expor configurações como variáveis de ambiente ou permitir a substituição de configurações de arquivos Python no volume de dados.

Substituindo o logotipo e outros arquivos estáticos

Os arquivos estáticos que vêm com Weblate podem ser sobrescritos colocando em /app/data/python/customize/static (consulte Volumes de contêiner Docker). Por exemplo, criar /app/data/python/customize/static/favicon.ico substituirá o favicon.

Dica

Os arquivos são copiados para o local correspondente na inicialização do contêiner, portanto, é necessário reiniciar o Weblate após alterar o conteúdo do volume.

This approach can be also used to override Weblate templates. For example Legal module documents can be placed into /app/data/python/customize/templates/legal/documents.

Como alternativa, você também pode incluir o próprio módulo (veja Personalizando o Weblate) e adicioná-lo como um volume separado ao contêiner do Docker, por exemplo:

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

Customizing code

Nota

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

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

This can be used to place any code (for example Escrevendo as próprias verificações) or to add custom maintenance tasks to the Celery task scheduler.

An example of custom scheduled tasks in /app/data/python/customize/tasks.py.
"""Custom scheduled task."""

import subprocess  # noqa: S404

from celery.schedules import crontab

from weblate.utils.celery import app


@app.task
def custom_task() -> None:
    """Execute custom task code."""
    subprocess.run(["sleep", "1"], check=True)  # noqa: S607


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

Integrating third-party containers

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

When adding third-party containers, consider the following:

  • Network connectivity: Ensure containers can communicate with each other by placing them on the same Docker network

  • Data persistence: Use volumes for services that need to persist data

  • Security: Configure appropriate access controls and avoid exposing unnecessary ports

LibreTranslate Docker container integration

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

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

Basic setup using docker-compose.override.yml:

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

volumes:
  libretranslate_models:

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

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

volumes:
  libretranslate_models:

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

  1. Access the Weblate admin interface

  2. Navigate to Machine translation → Automatic suggestions

  3. Add a new LibreTranslate service with:

    Serviço:

    LibreTranslate

    URL da API:

    http://libretranslate:5000

    Chave da API:

    Leave empty

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

Nota

  • The LibreTranslate service runs without the web UI (--disable-web-ui) and is only accessible via the API within the Docker network.

  • Models are automatically updated when the container starts. (LT_UPDATE_MODELS: true)

  • Data is persisted using Docker volumes for optimal performance and data safety.

  • Health checks ensure that the Docker engine properly observes the state of the service.

  • For GPU acceleration, use the CUDA image variant and ensure your system has NVIDIA Docker support. This container runs as a privileged user to be able to use the GPU.

  • No external ports are exposed, making the setup secure by default.

Ver também

Anubis Docker container integration

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

Anubis can be deployed using Docker Compose:

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

volumes:
   anubis-data:

Nota

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

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

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

Você pode ativar o uso do Anubis no Weblate usando:

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

Ver também

WEBLATE_ANUBIS_URL

Configurando o servidor PostgreSQL

O contêiner PostgreSQL usa a configuração padrão do PostgreSQL e não utilizará efetivamente seus núcleos de CPU ou memória. Recomenda-se personalizar a configuração para melhorar o desempenho.

A configuração pode ser ajustada conforme descrito em Database Configuration em https://hub.docker.com/_/postgres. A configuração correspondente ao seu ambiente pode ser gerada usando https://pgtune.leopard.in.ua/.

Partes internas do contêiner

O contêiner está usando supervisor para iniciar serviços individuais. No caso de Dimensionamento horizontal, ele inicia apenas um único serviço em um contêiner.

Para verificar o status dos serviços, use:

docker compose exec --user weblate weblate supervisorctl status

Existem serviços individuais para cada fila Celery (consulte Tarefas de fundo usando Celery para detalhes). Você pode interromper o processamento de algumas tarefas parando o worker apropriado:

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