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.
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 webserver):
2 GB of RAM
2 CPU cores
1 GB of storage space
The more memory the better - it is used for caching on all levels (filesystem, database and Weblate).
Many concurrent users increases the amount of needed CPU cores. For hundreds of translation components at least 4 GB of RAM is recommended.
The typical database storage usage is around 300 MB per 1 million hosted words. Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.
Note
Actual requirements for your installation of Weblate vary heavily based on the size of the translations managed in it.
Installation
The following examples assume you have a working Docker environment, with
docker-compose
installed. Please check the Docker documentation for instructions.
Clone the weblate-docker repo:
git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker cd weblate-docker
Create a
docker-compose.override.yml
file with your settings. See Docker environment variables for full list of environment variables.version: '3' services: weblate: ports: - 80:8080 environment: WEBLATE_EMAIL_HOST: smtp.example.com WEBLATE_EMAIL_HOST_USER: user WEBLATE_EMAIL_HOST_PASSWORD: pass WEBLATE_SERVER_EMAIL: weblate@example.com WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com WEBLATE_SITE_DOMAIN: weblate.example.com WEBLATE_ADMIN_PASSWORD: password for the admin user WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
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.Start Weblate containers:
docker-compose up
Enjoy your Weblate deployment, it’s accessible on port 80 of the weblate
container.
Changed in version 2.15-2: The setup has changed recently, priorly there was separate web server container, since 2.15-2 the web server is embedded in the Weblate container.
Changed in version 3.7.1-6: In July 2019 (starting with the 3.7.1-6 tag), the containers are not running as a root user. This has changed the exposed port from 80 to 8080.
See also
Choosing Docker hub tag
You can use following tags on Docker hub, see https://hub.docker.com/r/weblate/weblate/tags/ for full list of available ones.
Tag name |
Description |
Use case |
---|---|---|
|
Weblate stable release, matches latest tagged release |
Rolling updates in a production environment |
|
Weblate stable release |
Well defined deploy in a production environment |
|
Weblate stable release with development changes in the Docker container (for example updated dependencies) |
Rolling updates in a staging environment |
|
Weblate stable release with development changes in the Docker container (for example updated dependencies) |
Well defined deploy in a staging environment |
|
Development version Weblate from Git |
Rollling updates to test upcoming Weblate features |
|
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.
Docker container with HTTPS support
Please see Installation for generic deployment instructions, this section only mentions differences compared to it.
Using own SSL certificates
New in version 3.8-3.
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 certificatesssl/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;
listen [::]:443;
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.10-1: Since Weblate 4.10-1, the Docker container uses Django 4.0 what requires PostgreSQL 10 or newer, please upgrade it prior to upgrading Weblate. See Upgrade from 4.9 to 4.10 and 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 3.0 are not supported by Weblate. If you are on 2.x series
and want to upgrade to 3.x, first upgrade to the latest 3.0.1-x (at time of
writing this it is the 3.0.1-7
) image, 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.
Stop Weblate container:
docker-compose stop weblate cache
Backup the database:
docker-compose exec database pg_dumpall --clean --username weblate > backup.sql
Stop the database container:
docker-compose stop database
Remove the PostgreSQL volume
docker-compose rm -v database docker volume remove weblate_postgres-data
Adjust
docker-compose.yml
to use new PostgreSQL version.Start the database container:
docker-compose up -d database
Restore the database from the backup:
cat backup.sql | docker-compose exec -T database psql --username weblate --dbname postgres
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
Scaling horizontally
New in version 4.6.
Warning
This feature is a technology preview.
You can run multiple Weblate containers to scale the service horizontally. The
/app/data
volume has to be shared by all containers, it is recommended
to use cluster filesystem such as GlusterFS for this. The /app/cache
volume should be separate for each container.
Each Weblate container has defined role using WEBLATE_SERVICE
environment variable. Please follow carefully the documentation as some of the
services should be running just once in the cluster and the ordering of the
services matters as well.
You can find example setup in the docker-compose
repo as
docker-compose-split.yml.
Docker environment variables
Many of Weblate’s Configuration can be set in the Docker container using environment variables:
Generic settings
- WEBLATE_DEBUG
Configures Django debug mode using
DEBUG
.Example:
environment: WEBLATE_DEBUG: 1
See also
- WEBLATE_LOGLEVEL
Configures the logging 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.
See also
- 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 (seeWEBLATE_ADMIN_PASSWORD
for more info on that).Example:
environment: WEBLATE_ADMIN_NAME: Weblate admin WEBLATE_ADMIN_EMAIL: noreply@example.com
See also
- 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
andWEBLATE_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_PASSWORD_FILE
Sets the path to a file containing the password for the admin user.
See also
- WEBLATE_SERVER_EMAIL
The email address that error messages are sent from.
See also
- WEBLATE_DEFAULT_FROM_EMAIL
Configures the address for outgoing e-mails.
See also
- 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_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_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 setsIP_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 toHTTP_X_FORWARDED_FOR
.Example:
environment: WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
- 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
See also
- 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
andREMOVE
variables.
- WEBLATE_GOOGLE_ANALYTICS_ID
Configures ID for Google Analytics by changing
GOOGLE_ANALYTICS_ID
.
- WEBLATE_GITHUB_USERNAME
Configures GitHub username for GitHub pull-requests by changing
GITHUB_USERNAME
.See also
- WEBLATE_GITHUB_TOKEN
New in version 4.3.
Configures GitHub personal access token for GitHub pull-requests via API by changing
GITHUB_TOKEN
.See also
- WEBLATE_GITLAB_USERNAME
Configures GitLab username for GitLab merge-requests by changing
GITLAB_USERNAME
See also
- WEBLATE_GITLAB_TOKEN
Configures GitLab personal access token for GitLab merge-requests via API by changing
GITLAB_TOKEN
See also
- WEBLATE_PAGURE_USERNAME
Configures Pagure username for Pagure merge-requests by changing
PAGURE_USERNAME
See also
- WEBLATE_PAGURE_TOKEN
Configures Pagure personal access token for Pagure merge-requests via API by changing
PAGURE_TOKEN
See also
- WEBLATE_DEFAULT_PULL_MESSAGE
Configures the default title and message for pull requests via API by changing
DEFAULT_PULL_MESSAGE
See also
- 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
.See also
- WEBLATE_URL_PREFIX
Configures URL prefix where Weblate is running, see
URL_PREFIX
.
- WEBLATE_SILENCED_SYSTEM_CHECKS
Configures checks which you do not want to be displayed, see
SILENCED_SYSTEM_CHECKS
.
- WEBLATE_CSP_SCRIPT_SRC
- WEBLATE_CSP_IMG_SRC
- WEBLATE_CSP_CONNECT_SRC
- WEBLATE_CSP_STYLE_SRC
- WEBLATE_CSP_FONT_SRC
Allows to customize
Content-Security-Policy
HTTP header.
- 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
New 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
New in version 4.11.
Configures API rate limiting. Defaults to
100/day
for anonymous and5000/hour
for authenticated users.See also
- WEBLATE_ENABLE_AVATARS
New in version 4.6.1.
Configures
ENABLE_AVATARS
.
- WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
New in version 4.9.
Configures
LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
.
- WEBLATE_SSH_EXTRA_ARGS
New in version 4.9.
Configures
SSH_EXTRA_ARGS
.
- WEBLATE_BORG_EXTRA_ARGS
New in version 4.9.
Configures
BORG_EXTRA_ARGS
.
Machine translation settings
Hint
Configuring API key for a service automatically configures it in MT_SERVICES
.
- WEBLATE_MT_APERTIUM_APY
Enables Apertium machine translation and sets
MT_APERTIUM_APY
- WEBLATE_MT_AWS_REGION
- WEBLATE_MT_AWS_ACCESS_KEY_ID
- WEBLATE_MT_AWS_SECRET_ACCESS_KEY
Configures AWS machine translation.
environment: WEBLATE_MT_AWS_REGION: us-east-1 WEBLATE_MT_AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE WEBLATE_MT_AWS_SECRET_ACCESS_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
- WEBLATE_MT_DEEPL_KEY
Enables DeepL machine translation and sets
MT_DEEPL_KEY
- WEBLATE_MT_DEEPL_API_URL
Configures DeepL API version to use, see
MT_DEEPL_API_URL
.
- WEBLATE_MT_LIBRETRANSLATE_KEY
Enables LibreTranslate machine translation and sets
MT_LIBRETRANSLATE_KEY
- WEBLATE_MT_LIBRETRANSLATE_API_URL
Configures LibreTranslate API instance to use, see
MT_LIBRETRANSLATE_API_URL
.
- WEBLATE_MT_GOOGLE_KEY
Enables Google Translate and sets
MT_GOOGLE_KEY
- WEBLATE_MT_GOOGLE_CREDENTIALS
Enables Google Translate API V3 (Advanced) and sets
MT_GOOGLE_CREDENTIALS
- WEBLATE_MT_GOOGLE_PROJECT
Enables Google Translate API V3 (Advanced) and sets
MT_GOOGLE_PROJECT
- WEBLATE_MT_GOOGLE_LOCATION
Enables Google Translate API V3 (Advanced) and sets
MT_GOOGLE_LOCATION
- WEBLATE_MT_MICROSOFT_COGNITIVE_KEY
Enables Microsoft Cognitive Services Translator and sets
MT_MICROSOFT_COGNITIVE_KEY
- WEBLATE_MT_MICROSOFT_ENDPOINT_URL
Sets
MT_MICROSOFT_ENDPOINT_URL
, please note this is supposed to contain domain name only.
- WEBLATE_MT_MICROSOFT_REGION
Sets
MT_MICROSOFT_REGION
- WEBLATE_MT_MICROSOFT_BASE_URL
- WEBLATE_MT_MODERNMT_KEY
Enables ModernMT and sets
MT_MODERNMT_KEY
.
- WEBLATE_MT_MYMEMORY_ENABLED
Enables MyMemory machine translation and sets
MT_MYMEMORY_EMAIL
toWEBLATE_ADMIN_EMAIL
.Example:
environment: WEBLATE_MT_MYMEMORY_ENABLED: 1
- WEBLATE_MT_GLOSBE_ENABLED
Enables Glosbe machine translation.
environment: WEBLATE_MT_GLOSBE_ENABLED: 1
- WEBLATE_MT_MICROSOFT_TERMINOLOGY_ENABLED
Enables Microsoft Terminology Service machine translation.
environment: WEBLATE_MT_MICROSOFT_TERMINOLOGY_ENABLED: 1
- WEBLATE_MT_SAP_BASE_URL
- WEBLATE_MT_SAP_SANDBOX_APIKEY
- WEBLATE_MT_SAP_USERNAME
- WEBLATE_MT_SAP_PASSWORD
- WEBLATE_MT_SAP_USE_MT
Configures SAP Translation Hub machine translation.
environment: WEBLATE_MT_SAP_BASE_URL: "https://example.hana.ondemand.com/translationhub/api/v1/" WEBLATE_MT_SAP_USERNAME: "user" WEBLATE_MT_SAP_PASSWORD: "password" WEBLATE_MT_SAP_USE_MT: 1
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
- 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)
See also
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.
Bitbucket
- 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.
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
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_UBUNTU
Slack
- WEBLATE_SOCIAL_AUTH_SLACK_KEY
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
SAML Identity Provider settings, see SAML authentication.
Other authentication settings
- WEBLATE_NO_EMAIL_AUTH
Disables e-mail authentication when set to any value. See Turning off password authentication.
PostgreSQL database setup
The database is created by docker-compose.yml
, so these settings affect
both Weblate and PostgreSQL containers.
See also
- POSTGRES_PASSWORD
PostgreSQL password.
- POSTGRES_PASSWORD_FILE
Path to the file containing the PostgreSQL password. Use as an alternative to POSTGRES_PASSWORD.
- POSTGRES_USER
PostgreSQL username.
- POSTGRES_DATABASE
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
New 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 (this is the default behavior).
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
See also
- POSTGRES_DISABLE_SERVER_SIDE_CURSORS
New 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
Database backup settings
See also
- WEBLATE_DATABASE_BACKUP
Configures the daily database dump using
DATABASE_BACKUP
. Defaults toplain
.
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
- 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.
- 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
See also
- WEBLATE_EMAIL_HOST
Mail server hostname or IP address.
- WEBLATE_EMAIL_PORT
Mail server port, defaults to 25.
See also
- WEBLATE_EMAIL_HOST_USER
E-mail authentication user.
See also
- WEBLATE_EMAIL_HOST_PASSWORD
E-mail authentication password.
See also
- WEBLATE_EMAIL_HOST_PASSWORD_FILE
Path to the file containing the e-mail authentication password.
See also
- 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
.See also
- 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
.See also
- WEBLATE_EMAIL_BACKEND
Configures Django back-end to use for sending e-mails.
See also
- WEBLATE_AUTO_UPDATE
Configures if and how Weblate should update repositories.
See also
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
.
- WEBLATE_PRIVACY_URL
Configures
PRIVACY_URL
.
Error reporting
It is recommended to collect errors from the installation systematically, see Collecting error reports.
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.
- SENTRY_ENVIRONMENT
Your Sentry Environment (optional).
Localization CDN
- WEBLATE_LOCALIZE_CDN_URL
- WEBLATE_LOCALIZE_CDN_PATH
New 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 or autofixes
New in version 3.8-5.
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
Example:
environment:
WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon
See also
Container settings
- WEBLATE_WORKERS
New 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
, andWEB_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
- 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 used to store Weblate persistent data such as cloned repositories or to customize Weblate installation.
The placement of the Docker volume on host system depends on your Docker
configuration, but usually it is stored in
/var/lib/docker/volumes/weblate-docker_weblate-data/_data/
(the path
consist of name of your docker-compose directory, container, and volume names).
In the container it is mounted as /app/data
.
The cache volume is mounted as /app/cache
and is used to store static
files. 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.
See also
Further configuration customization
You can further customize Weblate installation in the data volume, see Docker container volumes.
Custom configuration files
You can additionally override the configuration in
/app/data/settings-override.py
(see Docker container volumes). This is
executed at the end of built-in settings, after all environment settings
are loaded, and you can adjust or override them.
Replacing logo and other static files
New in version 3.8-5.
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
Adding own Python modules
New in version 3.8-5.
You can place own Python modules in /app/data/python/
(see
Docker container volumes) and they can be then loaded by Weblate, most likely by
using Custom configuration files.
See also