Hardening Weblate Access Control
To prevent accidental public access to a Weblate instance, you must implement a layered defense that combines Django application settings with network-level restrictions. Relying on a single configuration point is insufficient if the host firewall is misconfigured.
Strongest Protection Against Direct Port Access
The most effective combination to prevent direct access to the application port (bypassing the proxy) is a strict ALLOWED_HOSTS configuration paired with a reverse proxy that handles all external traffic.
- ALLOWED_HOSTS: Set this to the specific internal DNS name or IP address of your reverse proxy. If a request reaches the Weblate container/process with a
Host header that does not match this list, Django will return a 400 Bad Request. This prevents attackers from accessing the instance via the server's raw IP address if the firewall is open.
- Reverse Proxy (Nginx/Apache): Configure the proxy to listen on public ports (80/443) and forward traffic to the internal Weblate port. To harden this, implement IP Whitelisting at the proxy level to ensure only known corporate or VPN IP ranges can reach the application.
- Binding: Ensure the Weblate service is bound to
127.0.0.1 or a private Docker network interface, rather than 0.0.0.0, to prevent the OS from exposing the port to the external network interface entirely.
Mitigating Search Engine Indexing
Disabling registration via REGISTRATION_OPEN=False (or PUBLIC_SIGNUP=False depending on version) does not mitigate the risk of search engine indexing. Indexing is based on the visibility of the pages, not the ability to create an account.
To prevent indexing of internal instances, you must implement one of the following:
- Robots.txt: Add a
robots.txt file to the root of the site with Disallow: /.
- X-Robots-Tag: Configure your reverse proxy to inject the header
X-Robots-Tag: noindex, nofollow into all responses.
- Authentication: The most reliable method is implementing Basic Auth or an OIDC provider at the reverse proxy level, which blocks crawlers entirely.
Verification Steps
To verify your configuration, perform these scoped tests:
- Direct IP Test: Attempt to access the instance using
http://[Server-IP]:[Weblate-Port]. You should receive a connection timeout (firewall) or a 400 Bad Request (ALLOWED_HOSTS).
- Registration Test: Navigate to the signup page. It should redirect or display a message stating that registration is closed.
- Header Check: Use
curl -I [your-url] to verify that the X-Robots-Tag is present if configured.
Diagnostic Detail Required: Are you deploying Weblate via Docker Compose or a bare-metal installation? This changes whether you should focus on Docker network isolation or OS-level iptables binding.
weblate