LibreTranslate: a self-hosted translation API backed by Argos Translate

What LibreTranslate does that a hosted translation API cannot

The core claim in the README is narrow and specific: LibreTranslate is a "Free and Open Source Machine Translation API, entirely self-hosted", and it "doesn't rely on proprietary software such as Google or Azure to perform translations". That sentence defines both the audience and the constraint. If your text is allowed to leave your network, the hosted alternatives are easier. If it is not, LibreTranslate is one of the few options that gives you a translation endpoint you control.

The people who benefit are the ones with a data boundary: internal documentation that cannot be sent to a third party, an air-gapped environment, or a product that must keep working when an external API is unreachable. The README describes the project as "offline capable", which follows from the engine being local rather than remote. The translation engine is Argos Translate, credited in the README as the component that "powers the translation engine".

This is not a thin wrapper around someone else's cloud. The dependency list in pyproject.toml pins argos-translate-lt==1.12.1, so the model runtime ships with the application. Everything else in that list is ordinary web service plumbing: Flask, waitress, Flask-Limiter for request limits, Flask-Babel for localisation, langdetect, redis, prometheus-client. That shape tells you what kind of project this is. It is a service around a translation library, not a research project.

How the request path works, from HTTP call to Argos model

The repository layout is conventional for a Flask application packaged for distribution. main.py and wsgi.py sit at the top level as entry points, libretranslate/ holds the application package, and db/ holds storage. The pyproject.toml declares two console scripts: libretranslate, which maps to libretranslate.main:main, and ltmanage, whose target is truncated in the file but whose name follows the same pattern. The first runs the server; the second is the management command.

A translation request arrives over HTTP, passes through the Flask application, and is handed to the Argos Translate engine. Language detection is available through langdetect, which matters because the API can accept text without a source language. Rate limiting is handled by Flask-Limiter, and the docker-compose.yml comment shows the flags that control it: --req-limit 100 --char-limit 500. Those are the two knobs that decide how much work a single caller can push through the service.

State lives in two places. API keys, when enabled, are stored in a SQLite database, and the compose file points LT_API_KEYS_DB_PATH at /app/db/api_keys.db. Translation models live in the user's local data directory, which the compose file mounts as a volume at /home/libretranslate/.local. That second mount is the one that decides whether a container restart means re-downloading every model. The compose file comments it out by default, with a note that keeping models in a volume avoids re-downloading on startup.

Scheduling is present too: APScheduler is a dependency, and the compose file mentions LT_UPDATE_MODELS. Model updates are therefore a background concern rather than something you trigger by hand.

Installing LibreTranslate with Docker Compose

The repository ships a docker-compose.yml that runs the published image libretranslate/libretranslate:latest and maps port 5000 to 5000. The healthcheck runs scripts/healthcheck.py through the bundled virtual environment, with an interval of 10s and a start period of 5s. Bring it up with:

docker compose up -d

The container name is libretranslate and the restart policy is unless-stopped, so it comes back after a host reboot. Once the healthcheck passes, the API is listening on port 5000 on the host.

The default compose file is deliberately minimal, and the parts you will probably want are commented out. To keep models between restarts, uncomment the models volume and the environment variables that go with it:

    environment:
      - LT_UPDATE_MODELS=true
      - LT_LOAD_ONLY=en,fr
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw

LT_LOAD_ONLY restricts which languages are loaded, which is the difference between a fast start and a long one. To require API keys, uncomment the key variables and the api keys volume instead:

    environment:
      - LT_API_KEYS=true
      - LT_API_KEYS_DB_PATH=/app/db/api_keys.db
    volumes:
      - libretranslate_api_keys:/app/db

Without LT_API_KEYS, the endpoint accepts requests from anyone who can reach port 5000. On a laptop that is fine. On a public host it is not, and the compose file leaves that decision to you. There is also a docker-compose.cuda.yml in the repository for GPU hosts, and a k8s.yaml if you deploy to Kubernetes rather than Compose.

Installing LibreTranslate from PyPI and calling the API

The package is published as libretranslate, and pyproject.toml requires Python 3.8 or newer, with classifiers up to 3.13. The console script entry point means you can start the server directly after installing:

pip install libretranslate
libretranslate

The second command is the entry point defined in pyproject.toml as libretranslate = "libretranslate.main:main". It starts the server, and the first run downloads the Argos Translate models it needs. That download is the slow part, and it is the reason the Docker instructions mount a models volume.

Once the server is up, a translation is a single POST with the text, the source language and the target language. The README links to an API usage guide rather than embedding the request format, so check that guide for the exact field names before wiring it into an application. The shape is the usual JSON body, and the response carries the translated text.

For a first real use, keep the language set small. Setting LT_LOAD_ONLY to the pairs you actually serve shortens startup and reduces memory, and it is also the setting that makes a container's behaviour predictable. If your deployment is behind a load balancer or exposed to the internet, turn on LT_API_KEYS at the same time, because there is no other authentication layer described in the compose file.

Where LibreTranslate falls short

The honest limitation is translation quality. LibreTranslate runs Argos Translate models locally, and locally run open models are not the same thing as the large commercial engines. The README makes no accuracy claim at all, and the comparison it draws with Google and Azure is about dependency and licensing, not output quality. If your content is marketing copy or anything where tone matters, expect to review and edit the output.

Language coverage is the second constraint. Argos Translate works on installed model pairs, and the compose file's LT_LOAD_ONLY example only lists en and fr. Coverage depends on which models exist and which you load, so a pair you need may not be available at all. Verify the pairs you care about before you design around this API.

Resource use is the third. The models are downloaded and held locally, and numpy is pinned differently for Python 3.12 and below versus 3.13 and above, which indicates the numerical stack is version-sensitive. A small container will not behave like a thin API client. The repository also includes docker-compose.cuda.yml, which suggests GPU acceleration is a supported path, but the default compose file does not use it.

Finally, there is the licence. AGPL-3.0 is a strong copyleft licence, and if you modify LibreTranslate and expose it over a network, the obligations reach your users. The repository also carries a separate TRADEMARK.md, so the name has its own guidelines distinct from the code licence.

LibreTranslate compared with DeepL and Google Translate

The difference is architectural, not incremental. DeepL and Google Translate are hosted services: you send text to their infrastructure, they return a translation, and you pay per volume or per plan. LibreTranslate inverts that. The engine runs in your process, on your hardware, and the text never leaves. That is the whole trade. You give up the quality of a large proprietary model and the operational simplicity of a managed endpoint, and you get control over where the data goes.

Against a general-purpose LLM translator the trade is different again. An LLM can handle context and tone in ways a dedicated translation model does not, but it is a remote service with per-token cost, and it is not designed as a translation API with language listing and rate limits. LibreTranslate's surface is narrower on purpose: a translation endpoint, a set of installed language pairs, and request limits you configure.

Against Argos Translate used directly, LibreTranslate adds the HTTP layer, API keys, rate limiting, language detection, metrics through prometheus-client, and the management command. If you only need to translate files in a script, the library underneath is the smaller dependency. If you need a service other systems call, LibreTranslate is the packaging around it.

Maintenance, releases and what the licence means for a product

The last push to the repository was on 2026-09-03, and the most recent release listed is v1.9.6 from 2026-05-26, preceded by v1.9.5 in March 2026 and v1.9.4 in February 2026. The project is not archived. The dependency pins are tight, with exact versions on Flask, waitress, redis and argos-translate-lt, which is good for reproducibility and less good for absorbing upstream security fixes without a release. If you self-host, plan to track releases rather than pin and forget.

The upgrade cost is mostly model and environment related. Changing LT_LOAD_ONLY changes which models get pulled, and a models volume that is not mounted means re-downloading on every container start. The Python version matters too: the numpy pin differs between 3.12 and below and 3.13 and above, so an interpreter upgrade is a real change, not a formality.

On licensing, AGPL-3.0 is the code licence and the README points to TRADEMARK.md separately. I am not giving legal advice here, but the practical point is that AGPL-3.0 is not a permissive licence, and the network clause is the part teams most often miss. If LibreTranslate sits behind a public interface, read the licence before you build a product on it.

Editorial conclusion

Adopt LibreTranslate when the text cannot leave your infrastructure and an offline-capable API matters more than top-tier fluency. Do not adopt it if you need the output quality of a large commercial or LLM-based translator, or if AGPL-3.0 obligations conflict with how you ship your product. Before committing, verify which language pairs your deployment actually loads, confirm the model download behaviour on first start, and check whether you need the API key settings that docker-compose.yml leaves commented out.

Frequently asked questions

Official sources

1. LibreTranslate/LibreTranslate on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases