Installing using Docker¶
With dockerized Weblate deployment you can get your personal Weblate instance up and running in seconds. All of Weblate’s dependencies are already included. PostgreSQL is set up as the default database and Redis as a caching backend.
Hardware requirements¶
Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):
3 GB of RAM
2 CPU cores
1 GB of storage space
Note
Actual requirements for your installation of Weblate vary heavily based on the size of the translations managed in it.
Memory usage¶
The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.
Hint
For systems with less memory than recommended, Single-process Celery setup is recommended.
CPU usage¶
Many concurrent users increase the amount of needed CPU cores.
Storage usage¶
The typical database storage usage is around 300 MB per 1 million hosted words.
Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.
Nodes¶
For small and medium-sized sites (millions of hosted words), all Weblate components (see Architecture overview) can be run on a single node.
When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Database setup for Weblate).
Installation¶
Hint
The following examples assume you have a working Docker environment, with
docker-compose-plugin
installed. Please check the Docker documentation
for instructions.
This creates a Weblate deployment server via HTTP, so you should place it behind HTTPS terminating proxy. You can also deploy with a HTTPS proxy, see Automatic SSL certificates using Let’s Encrypt. For larger setups, please see Scaling horizontally.
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.
See also
Choosing Docker image registry¶
Weblate containers are published to following registries:
Docker Hub, see https://hub.docker.com/r/weblate/weblate
GitHub Packages registry, see https://github.com/WeblateOrg/docker/pkgs/container/weblate
Note
All examples currently fetch images from Docker Hub, please adjust the configuration accordingly to use a different registry.
Choosing Docker image tag¶
Please choose a tag that matches your environment and expectations:
Tag name |
Description |
Use case |
---|---|---|
|
Weblate stable release, matches latest tagged release |
Rolling updates in a production environment |
|
Weblate stable release |
Rolling updates within a major version in a production environment |
|
Weblate stable release |
Rolling updates within a minor version 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.
Full list of published tags can be found at GitHub Packages
Docker container with HTTPS support¶
Please see Installation for generic deployment instructions, this section only mentions differences compared to it.
Using own SSL certificates¶
In case you have own SSL certificate you want to use, simply place the files into the Weblate data volume (see Docker container volumes):
ssl/fullchain.pem
containing the certificate including any needed CA 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 ssl;
listen [::]:443 ssl;
server_name <SITE_URL>;
ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;
location / {
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
}
}
Replace <SITE_URL>
, <SITE>
and <EXPOSED_DOCKER_PORT>
with actual values from your environment.
Automatic SSL certificates using Let’s Encrypt¶
In case you want to use Let’s Encrypt
automatically generated SSL certificates on public installation, you need to
add a reverse HTTPS proxy an additional Docker container, https-portal will be used for that.
This is made use of in the docker-compose-https.yml
file. Then create
a docker-compose-https.override.yml
file with your settings:
version: '3'
services:
weblate:
environment:
WEBLATE_EMAIL_HOST: smtp.example.com
WEBLATE_EMAIL_HOST_USER: user
WEBLATE_EMAIL_HOST_PASSWORD: pass
WEBLATE_SITE_DOMAIN: weblate.example.com
WEBLATE_ADMIN_PASSWORD: password for admin user
https-portal:
environment:
DOMAINS: 'weblate.example.com -> http://weblate:8080'
Whenever invoking docker compose you need to pass both files to it, and then do:
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up
Upgrading the Docker container¶
Usually it is good idea to only update the Weblate container and keep the PostgreSQL container at the version you have, as upgrading PostgreSQL is quite painful and in most cases does not bring many benefits.
Changed in version 4.17-1: Since Weblate 4.17-1, the Docker container uses Django 4.2 what requires PostgreSQL 12 or newer, please upgrade it prior to upgrading Weblate. See Upgrading PostgreSQL container.
You can do this by sticking with the existing docker-compose and just pull the latest images and then restart:
# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f
The Weblate database should be automatically migrated on first startup, and there should be no need for additional manual actions.
Note
Upgrades across major versions are not supported by Weblate. For example,
if you are on 3.x series and want to upgrade to 4.x, first upgrade to the
latest 4.0.x-y image (at time of writing this it is the 4.0.4-5
), which
will do the migration and then continue upgrading to newer versions.
You might also want to update the docker-compose
repository, though it’s
not needed in most case. See Upgrading PostgreSQL container for upgrading the PostgreSQL server.
Upgrading PostgreSQL container¶
PostgreSQL containers do not support automatic upgrading between version, you need to perform the upgrade manually. Following steps show one of the options of upgrading.
Stop Weblate container:
docker compose stop weblate cache
Backup the database:
docker compose exec database pg_dumpall --clean --if-exists --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-docker_postgres-data
Hint
The volume name contains name of the Docker Compose project, which is by default the directory name what is
weblate-docker
in this documentation.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 weblate
Hint
Please check that the database name matches
POSTGRES_DB
.(Optional) Update password for the Weblate user. This might be needed when migrating to PostgreSQL 14 or 15 as way of storing passwords has been changed:
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
Hint
Please check that the database name matches
POSTGRES_DB
.Start all remaining containers:
docker compose up -d
Admin sign in¶
After container setup, you can sign in as admin user with password provided
in WEBLATE_ADMIN_PASSWORD
, or a random password generated on first
start if that was not set.
To reset admin password, restart the container with
WEBLATE_ADMIN_PASSWORD
set to new password.
Number of processes and memory consumption¶
The number of worker processes for both uWSGI and Celery is determined automatically based on number of CPUs. This works well for most cloud virtual machines as these typically have few CPUs and good amount of memory.
In case you have a lot of CPU cores and hit out of memory issues, try reducing number of workers:
environment:
WEBLATE_WORKERS: 2
You can also fine-tune individual worker categories:
environment:
WEB_WORKERS: 4
CELERY_MAIN_OPTIONS: --concurrency 2
CELERY_NOTIFY_OPTIONS: --concurrency 1
CELERY_TRANSLATE_OPTIONS: --concurrency 1
Memory usage can be further reduced by running only a single Celery process:
environment:
CELERY_SINGLE_PROCESS: 1
Scaling horizontally¶
Added in version 4.6.
You can run multiple Weblate containers to scale the service horizontally. The
/app/data
volume has to be shared by all containers, it is recommended
to use cluster filesystem such as GlusterFS for this. The /app/cache
volume should be separate for each container.
Each Weblate container has defined role using WEBLATE_SERVICE
environment variable. Please follow carefully the documentation as some of the
services should be running just once in the cluster, and the order of the
services matters as well.
You can find example setup in the docker-compose
repo as
docker-compose-split.yml.
Docker environment variables¶
Many of Weblate’s Configuration can be set in the Docker container using the environment variables described below.
If you need to define a setting not exposed through Docker environment variables, see Configuration beyond environment variables.
Passing secrets¶
Added in version 5.0.
Weblate container supports passing secrets as files. To utilize that, append
_FILE
suffix to the environment variable and pass secret file via Docker.
Related docker-compose.yml
might look like:
services:
weblate:
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
database:
environment:
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
secrets:
db_password:
file: db_password.txt
See also
Generic settings¶
- WEBLATE_DEBUG¶
Configures Django debug mode using
DEBUG
.Example:
environment: WEBLATE_DEBUG: 1
See also
- WEBLATE_LOGLEVEL¶
Configures the logging verbosity. Set this to
DEBUG
to get more detailed logs.Defaults to
INFO
whenWEBLATE_DEBUG
is turned off,DEBUG
is used when debug mode is turned on.For more silent logging use
ERROR
orWARNING
.
- WEBLATE_LOGLEVEL_DATABASE¶
Configures the logging of the database queries verbosity.
- WEBLATE_SITE_TITLE¶
Changes the site-title shown in the header of all pages.
- WEBLATE_SITE_DOMAIN¶
Configures the site domain. This parameter is required.
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_NOTIFY_ERROR¶
Whether to sent e-mail to admins upon server error. Turned on by default.
You might want to use other error collection like Sentry or Rollbar and turn this off.
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_ADMINS_CONTACT¶
Configures
ADMINS_CONTACT
.
- WEBLATE_CONTACT_FORM¶
Configures contact form behavior, see
CONTACT_FORM
.
- WEBLATE_ALLOWED_HOSTS¶
Configures allowed HTTP hostnames using
ALLOWED_HOSTS
.Defaults to
*
which allows all hostnames.Example:
environment: WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com
- WEBLATE_REGISTRATION_OPEN¶
Configures whether registrations are open by toggling
REGISTRATION_OPEN
.Example:
environment: WEBLATE_REGISTRATION_OPEN: 0
- WEBLATE_REGISTRATION_ALLOW_BACKENDS¶
Configure which authentication methods can be used to create new account via
REGISTRATION_ALLOW_BACKENDS
.Example:
environment: WEBLATE_REGISTRATION_OPEN: 0 WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2
- WEBLATE_REGISTRATION_REBIND¶
Added in version 4.16.
Configures
REGISTRATION_REBIND
.
- WEBLATE_TIME_ZONE¶
Configures the used time zone in Weblate, see
TIME_ZONE
.Note
To change the time zone of the Docker container itself, use the
TZ
environment variable.Example:
environment: WEBLATE_TIME_ZONE: Europe/Prague
- WEBLATE_ENABLE_HTTPS¶
Makes Weblate assume it is operated behind a reverse HTTPS proxy, it makes Weblate use HTTPS in e-mail and API links or set secure flags on cookies.
Hint
Please see
ENABLE_HTTPS
documentation for possible caveats.Note
This does not make the Weblate container accept HTTPS connections, you need to configure that as well, see Docker container with HTTPS support for examples.
Example:
environment: WEBLATE_ENABLE_HTTPS: 1
- WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶
Added in version 4.12.1.
Lets Weblate set the meta[name=monetization] field in the head of the document. If multiple are specified, chooses one randomly.
See also
- 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_IP_PROXY_OFFSET¶
Added in version 5.0.1.
Configures
IP_PROXY_OFFSET
.
- WEBLATE_USE_X_FORWARDED_PORT¶
Added in version 5.0.1.
A boolean that specifies whether to use the X-Forwarded-Port header in preference to the SERVER_PORT META variable. This should only be enabled if a proxy which sets this header is in use.
See also
Note
This is a boolean setting (use
"true"
or"false"
).
- WEBLATE_SECURE_PROXY_SSL_HEADER¶
A tuple representing a HTTP header/value combination that signifies a request is secure. This is needed when Weblate is running behind a reverse proxy doing SSL termination which does not pass standard HTTPS headers.
Example:
environment: WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https
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.To enforce authentication for the contact form, do:
environment: WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$
- WEBLATE_GOOGLE_ANALYTICS_ID¶
Configures ID for Google Analytics by changing
GOOGLE_ANALYTICS_ID
.
- WEBLATE_DEFAULT_PULL_MESSAGE¶
Configures the default title and message for pull requests via API by changing
DEFAULT_PULL_MESSAGE
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¶
- WEBLATE_CSP_FORM_SRC¶
Allows to customize
Content-Security-Policy
HTTP header.
- WEBLATE_LICENSE_FILTER¶
Configures
LICENSE_FILTER
.
- WEBLATE_LICENSE_REQUIRED¶
Configures
LICENSE_REQUIRED
- WEBLATE_WEBSITE_REQUIRED¶
Configures
WEBSITE_REQUIRED
- WEBLATE_HIDE_VERSION¶
Configures
HIDE_VERSION
.
- WEBLATE_BASIC_LANGUAGES¶
Configures
BASIC_LANGUAGES
.
- WEBLATE_DEFAULT_AUTO_WATCH¶
Configures
DEFAULT_AUTO_WATCH
.
- WEBLATE_RATELIMIT_ATTEMPTS¶
- WEBLATE_RATELIMIT_LOCKOUT¶
- WEBLATE_RATELIMIT_WINDOW¶
Added in version 4.6.
Configures rate limiter.
Hint
You can set configuration for any rate limiter scopes. To do that add
WEBLATE_
prefix to any of setting described in Rate limiting.
- WEBLATE_API_RATELIMIT_ANON¶
- WEBLATE_API_RATELIMIT_USER¶
Added in version 4.11.
Configures API rate limiting. Defaults to
100/day
for anonymous and5000/hour
for authenticated users.See also
- WEBLATE_ENABLE_HOOKS¶
Added in version 4.13.
Configures
ENABLE_HOOKS
.
- WEBLATE_ENABLE_AVATARS¶
Added in version 4.6.1.
Configures
ENABLE_AVATARS
.
- WEBLATE_AVATAR_URL_PREFIX¶
Added in version 4.15.
Configures
AVATAR_URL_PREFIX
.
- WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶
Added in version 4.9.
Configures
LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH
.
- WEBLATE_SSH_EXTRA_ARGS¶
Added in version 4.9.
Configures
SSH_EXTRA_ARGS
.
- WEBLATE_BORG_EXTRA_ARGS¶
Added in version 4.9.
Configures
BORG_EXTRA_ARGS
as a comma separated list of args.Example:
environment: WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
- WEBLATE_ENABLE_SHARING¶
Added in version 4.14.1.
Configures
ENABLE_SHARING
.
- WEBLATE_SUPPORT_STATUS_CHECK¶
Added in version 5.5.
Configures
SUPPORT_STATUS_CHECK
.
- WEBLATE_EXTRA_HTML_HEAD¶
Added in version 4.15.
Configures
EXTRA_HTML_HEAD
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶
Added in version 4.15.
Configures
PRIVATE_COMMIT_EMAIL_TEMPLATE
.
- WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶
Added in version 4.15.
Configures
PRIVATE_COMMIT_EMAIL_OPT_IN
.
- WEBLATE_UNUSED_ALERT_DAYS¶
Added in version 4.17.
Configures
UNUSED_ALERT_DAYS
.
- WEBLATE_CORS_ALLOWED_ORIGINS¶
Added in version 4.16.
Allow CORS requests to API from given origins.
Example:
environment: WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org
- WEBLATE_CORS_ALLOW_ALL_ORIGINS¶
Added in version 5.6.1: Allows CORS requests to API from all origins.
- CLIENT_MAX_BODY_SIZE¶
Added in version 4.16.3.
Configures maximal body size accepted by the built-in web server.
environment: CLIENT_MAX_BODY_SIZE: 200m
Hint
This variable intentionally lacks
WEBLATE_
prefix as it is shared with third-party container used in Automatic SSL certificates using Let’s Encrypt.
Code hosting sites credentials¶
In the Docker container, the code hosting credentials can be configured either in separate variables or using a Python dictionary to set them at once. The following examples are for GitHub pull requests, but applies to all Version control integration with appropriately changed variable names.
An example configuration for GitHub might look like:
WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com
Will be used as:
GITHUB_CREDENTIALS = {
"api.github.com": {
"username": "api-user",
"token": "api-token",
}
}
Alternatively the Python dictionary can be provided as a string:
WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'
Or the path to a file containing the Python dictionary:
echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'
- WEBLATE_GITHUB_USERNAME¶
- WEBLATE_GITHUB_TOKEN¶
- WEBLATE_GITHUB_HOST¶
- WEBLATE_GITHUB_CREDENTIALS¶
Configures GitHub pull requests by changing
GITHUB_CREDENTIALS
.
- WEBLATE_GITLAB_USERNAME¶
- WEBLATE_GITLAB_TOKEN¶
- WEBLATE_GITLAB_HOST¶
- WEBLATE_GITLAB_CREDENTIALS¶
Configures GitLab merge requests by changing
GITLAB_CREDENTIALS
.
- WEBLATE_GITEA_USERNAME¶
- WEBLATE_GITEA_TOKEN¶
- WEBLATE_GITEA_HOST¶
- WEBLATE_GITEA_CREDENTIALS¶
Configures Gitea pull requests by changing
GITEA_CREDENTIALS
.
- WEBLATE_PAGURE_USERNAME¶
- WEBLATE_PAGURE_TOKEN¶
- WEBLATE_PAGURE_HOST¶
- WEBLATE_PAGURE_CREDENTIALS¶
Configures Pagure merge requests by changing
PAGURE_CREDENTIALS
.
- WEBLATE_BITBUCKETSERVER_USERNAME¶
- WEBLATE_BITBUCKETSERVER_TOKEN¶
- WEBLATE_BITBUCKETSERVER_HOST¶
- WEBLATE_BITBUCKETSERVER_CREDENTIALS¶
Configures Bitbucket Server pull requests by changing
BITBUCKETSERVER_CREDENTIALS
.
- WEBLATE_BITBUCKETCLOUD_USERNAME¶
- WEBLATE_BITBUCKETCLOUD_WORKSPACE¶
- WEBLATE_BITBUCKETCLOUD_TOKEN¶
- WEBLATE_BITBUCKETCLOUD_HOST¶
- WEBLATE_BITBUCKETCLOUD_CREDENTIALS¶
Configures Bitbucket Cloud pull requests by changing
BITBUCKETCLOUD_CREDENTIALS
.
- WEBLATE_AZURE_DEVOPS_USERNAME¶
- WEBLATE_AZURE_DEVOPS_ORGANIZATION¶
- WEBLATE_AZURE_DEVOPS_TOKEN¶
- WEBLATE_AZURE_DEVOPS_HOST¶
- WEBLATE_AZURE_DEVOPS_CREDENTIALS¶
Configures Azure DevOps pull requests by changing
AZURE_DEVOPS_CREDENTIALS
.
Automatic suggestion settings¶
Changed in version 4.13: Automatic suggestion services are now configured in the user interface, see Automatic suggestions.
The existing environment variables are imported during the migration to Weblate 4.13, but changing them will not have any further effect.
Authentication settings¶
LDAP¶
- WEBLATE_AUTH_LDAP_SERVER_URI¶
- WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶
- WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶
- WEBLATE_AUTH_LDAP_BIND_DN¶
- WEBLATE_AUTH_LDAP_BIND_PASSWORD¶
- WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS¶
- WEBLATE_AUTH_LDAP_USER_SEARCH¶
- 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.
GitHub Enterprise Edition¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶
- WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶
Enables GitHub EE authentication.
Bitbucket¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY¶
- WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET¶
Enables Bitbucket authentication.
Facebook¶
- WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶
- WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶
Enables Facebook OAuth 2.
Google¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS¶
- WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS¶
Enables Google OAuth 2.
GitLab¶
- WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶
- WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶
- WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶
Enables GitLab OAuth 2.
Gitea¶
- WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶
- WEBLATE_SOCIAL_AUTH_GITEA_KEY¶
- WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶
Enables Gitea authentication.
Azure Active Directory¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶
Enables Azure Active Directory authentication, see Microsoft Azure Active Directory.
Azure Active Directory with Tenant support¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶
- WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶
Enables Azure Active Directory authentication with Tenant support, see Microsoft Azure Active Directory.
Keycloak¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE¶
- WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE¶
Enables Keycloak authentication, see documentation.
Linux vendors¶
You can enable authentication using Linux vendors authentication services by setting following variables to any value.
- WEBLATE_SOCIAL_AUTH_FEDORA¶
- WEBLATE_SOCIAL_AUTH_OPENSUSE¶
- WEBLATE_SOCIAL_AUTH_OPENINFRA¶
- WEBLATE_SOCIAL_AUTH_UBUNTU¶
Slack¶
- WEBLATE_SOCIAL_AUTH_SLACK_KEY¶
OpenID Connect¶
Added in version 4.13-1.
- WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT¶
- WEBLATE_SOCIAL_AUTH_OIDC_KEY¶
- WEBLATE_SOCIAL_AUTH_OIDC_SECRET¶
- WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY¶
Configures generic OpenID Connect integration.
See also
SAML¶
Self-signed SAML keys are automatically generated on first container startup.
In case you want to use own keys, place the certificate and private key in
/app/data/ssl/saml.crt
and /app/data/ssl/saml.key
.
- WEBLATE_SAML_IDP_ENTITY_ID¶
- WEBLATE_SAML_IDP_URL¶
- WEBLATE_SAML_IDP_X509CERT¶
- WEBLATE_SAML_IDP_IMAGE¶
- WEBLATE_SAML_IDP_TITLE¶
SAML Identity Provider settings, see SAML authentication.
- WEBLATE_SAML_ID_ATTR_NAME¶
- WEBLATE_SAML_ID_ATTR_USERNAME¶
- WEBLATE_SAML_ID_ATTR_EMAIL¶
- WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶
Added in version 4.18.
SAML attributes mapping.
Other authentication settings¶
- WEBLATE_NO_EMAIL_AUTH¶
Disables e-mail authentication when set to any value. See Turning off password authentication.
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.
See also
- POSTGRES_USER¶
PostgreSQL username.
- POSTGRES_DB¶
PostgreSQL database name.
- POSTGRES_HOST¶
PostgreSQL server hostname or IP address. Defaults to
database
.
- POSTGRES_PORT¶
PostgreSQL server port. Defaults to none (uses the default value).
- POSTGRES_SSL_MODE¶
Configure how PostgreSQL handles SSL in connection to the server, for possible choices see SSL Mode Descriptions
- POSTGRES_ALTER_ROLE¶
Configures name of role to alter during migrations, see Configuring Weblate to use PostgreSQL.
- POSTGRES_CONN_MAX_AGE¶
Added in version 4.8.1.
The lifetime of a database connection, as an integer of seconds. Use 0 to close database connections at the end of each request.
Changed in version 5.1: The default behavior is to have unlimited persistent database connections.
Enabling connection persistence will typically, cause more open connection to the database. Please adjust your database configuration prior enabling.
Example configuration:
environment: POSTGRES_CONN_MAX_AGE: 3600
See also
- POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶
Added in version 4.9.1.
Disable server side cursors in the database. This is necessary in some pgbouncer setups.
Example configuration:
environment: POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1
- WEBLATE_DATABASES¶
Added in version 5.1.
Set to false to disables environment based configuration of the database connection. Use Overriding settings from the data volume to configure the database connection manually.
MySQL or MariaDB server¶
Neither MySQL nor MariaDB can not be configured via environment variables. See
MySQL and MariaDB for info on using those with Weblate. Use WEBLATE_DATABASES
to configure the database connection manually.
Database backup settings¶
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.
See also
- 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_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
.
Collecting error reports and monitoring performance¶
It is recommended to collect errors from the installation systematically, see Collecting error reports and monitoring performance.
To enable support for Rollbar, set the following:
- ROLLBAR_KEY¶
Your Rollbar post server access token.
- ROLLBAR_ENVIRONMENT¶
Your Rollbar environment, defaults to
production
.
To enable support for Sentry, set following:
- SENTRY_DSN¶
Your Sentry DSN, see
SENTRY_DSN
.
- SENTRY_ENVIRONMENT¶
Your Sentry Environment (optional), defaults to
WEBLATE_SITE_DOMAIN
.
- SENTRY_TRACES_SAMPLE_RATE¶
Configures
SENTRY_TRACES_SAMPLE_RATE
.Example:
environment: SENTRY_TRACES_SAMPLE_RATE: 0.5
- SENTRY_PROFILES_SAMPLE_RATE¶
Configures
SENTRY_PROFILES_SAMPLE_RATE
.Example:
environment: SENTRY_PROFILES_SAMPLE_RATE: 0.5
- SENTRY_SEND_PII¶
Configures
SENTRY_SEND_PII
.
Localization CDN¶
- WEBLATE_LOCALIZE_CDN_URL¶
- WEBLATE_LOCALIZE_CDN_PATH¶
Added in version 4.2.1.
Configuration for JavaScript localization CDN.
The
WEBLATE_LOCALIZE_CDN_PATH
is path within the container. It should be stored on the persistent volume and not in the transient storage.One of possibilities is storing that inside the Weblate data dir:
environment: WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/ WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn
Note
You are responsible for setting up serving of the files generated by Weblate, it only does stores the files in configured location.
Changing enabled apps, checks, add-ons, machine translation or autofixes¶
The built-in configuration of enabled checks, add-ons or autofixes can be adjusted by the following variables:
- WEBLATE_ADD_APPS¶
- WEBLATE_REMOVE_APPS¶
- WEBLATE_ADD_CHECK¶
- WEBLATE_REMOVE_CHECK¶
- WEBLATE_ADD_AUTOFIX¶
- WEBLATE_REMOVE_AUTOFIX¶
- WEBLATE_ADD_ADDONS¶
- WEBLATE_REMOVE_ADDONS¶
- WEBLATE_ADD_MACHINERY¶
Added in version 5.6.1.
- WEBLATE_REMOVE_MACHINERY¶
Added in version 5.6.1.
Example:
environment:
WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon
Container settings¶
- WEBLATE_WORKERS¶
Added in version 4.6.1.
Base number of worker processes running in the container. When not set it is determined automatically on container startup based on number of CPU cores available.
It is used to determine
CELERY_MAIN_OPTIONS
,CELERY_NOTIFY_OPTIONS
,CELERY_MEMORY_OPTIONS
,CELERY_TRANSLATE_OPTIONS
,CELERY_BACKUP_OPTIONS
,CELERY_BEAT_OPTIONS
, 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
- CELERY_SINGLE_PROCESS¶
Added in version 5.7.1: This variable can be set to
1
to run only one celery process. This reduces memory usage but may impact Weblate performance.environment: CELERY_SINGLE_PROCESS: 1
See also
- WEB_WORKERS¶
Configure how many uWSGI workers should be executed.
It defaults to
WEBLATE_WORKERS
.Example:
environment: WEB_WORKERS: 32
- WEBLATE_SERVICE¶
Defines which services should be executed inside the container. Use this for Scaling horizontally.
Following services are defined:
celery-beat
Celery task scheduler, only one instance should be running. This container is also responsible for the database structure migrations and it should be started prior others.
celery-backup
Celery worker for backups, only one instance should be running.
celery-celery
Generic Celery worker.
celery-memory
Translation memory Celery worker.
celery-notify
Notifications Celery worker.
celery-translate
Automatic translation Celery worker.
web
Web server.
Docker container volumes¶
There are two volumes (data
and cache
) exported by the Weblate container. The
other service containers (PostgreSQL or Redis) have their data volumes as well,
but those are not covered by this document.
The data
volume is mounted as /app/data
and is used to store
Weblate persistent data such as cloned repositories or to customize Weblate
installation. DATA_DIR
describes in more detail what is stored here.
The placement of the Docker volume on host system depends on your Docker
configuration, but usually it is stored in
/var/lib/docker/volumes/weblate-docker_weblate-data/_data/
(the path
consist of name of your docker-compose directory, container, and volume names).
The cache
volume is mounted as /app/cache
and is used to store static
files and CACHE_DIR
. Its content is recreated on container startup
and the volume can be mounted using ephemeral filesystem such as tmpfs.
When creating the volumes manually, the directories should be owned by UID 1000 as that is user used inside the container.
See also
Read-only root filesystem¶
Added in version 4.18.
When running the container with a read-only root filesystem, two additional
tmpfs volumes are required - /tmp
and /run
.
Configuration beyond environment variables¶
Docker environment variables are intended to expose most configuration settings of relevance for Weblate installations.
If you find a setting that is not exposed as an environment variable, and you believe that it should be, feel free to ask for it to be exposed in a future version of Weblate.
If you need to modify a setting that is not exposed as a Docker environment variable, you can still do so, either from the data volume or extending the Docker image.
See also
Overriding settings from the data volume¶
You can create a file at /app/data/settings-override.py
, i.e. at the
root of the data volume, to extend or override settings
defined through environment variables.
Overriding settings by extending the Docker image¶
To override settings at the Docker image level instead of from the data volume:
Add a module to your package that imports all settings from
weblate.settings_docker
.For example, within the example package structure defined at Creating a Python module, you could create a file at
weblate_customization/weblate_customization/settings.py
with the following initial code:from weblate.settings_docker import *
Create a custom
Dockerfile
that inherits from the official Weblate Docker image, and then installs your package and points theDJANGO_SETTINGS_MODULE
environment variable to your settings module:FROM weblate/weblate USER root COPY weblate_customization /usr/src/weblate_customization RUN /app/venv/bin/uv pip install --no-cache-dir /usr/src/weblate_customization ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings USER 1000
Instead of using the official Weblate Docker image, build a custom image from this
Dockerfile
file.There is no clean way to do this with
docker-compose.override.yml
. You could addbuild: .
to theweblate
node in that file, but then your custom image will be tagged asweblate/weblate
in your system, which could be problematic.So, instead of using the
docker-compose.yml
straight from the official repository, unmodified, and extending it throughdocker-compose.override.yml
, you may want to make a copy of the officialdocker-compose.yml
file, and edit your copy to replaceimage: weblate/weblate
withbuild: .
.See the Compose file build reference for details on building images from source when using
docker-compose
.Extend your custom settings module to define or redefine settings.
You can define settings before or after the import statement above to determine which settings take precedence. Settings defined before the import statement can be overridden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overridden.
You can also go further. For example, you can reproduce some of the things that
weblate.docker_settings
does, such as exposing settings as environment variables, or allow overriding settings from Python files in the data volume.
Replacing logo and other static files¶
The static files coming with Weblate can be overridden by placing into
/app/data/python/customize/static
(see Docker container volumes). For
example creating /app/data/python/customize/static/favicon.ico
will
replace the favicon.
Hint
The files are copied to the corresponding location upon container startup, so a restart of Weblate is needed after changing the content of the volume.
This approach can be also used to override Weblate templates. For example
Legal documents can be placed into
/app/data/python/customize/templates/legal/documents
.
Alternatively you can also include own module (see Customizing Weblate) and add it as separate volume to the Docker container, for example:
weblate:
volumes:
- weblate-data:/app/data
- ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
environment:
WEBLATE_ADD_APPS: weblate_customization
Configuring PostgreSQL server¶
The PostgreSQL container uses default PostgreSQL configuration and it won’t effectively utilize your CPU cores or memory. It is recommended to customize the configuration to improve the performance.
The configuration can be adjusted as described in Database Configuration at https://hub.docker.com/_/postgres. The configuration matching your environment can be generated using https://pgtune.leopard.in.ua/.
Container internals¶
The container is using supervisor to start individual services. In case of Scaling horizontally, it only starts single service in a container.
To check the services status use:
docker compose exec --user weblate weblate supervisorctl status
There are individual services for each Celery queue (see Background tasks using Celery for details). You can stop processing some tasks by stopping the appropriate worker:
docker compose exec --user weblate weblate supervisorctl stop celery-translate