LibreTranslate

Last reviewed Sep 13, 2026 · 760 words

The first thing to know about LibreTranslate is a flag, not a feature: LT_LOAD_ONLY=en,de,fr. Without it, the container downloads every language model it supports, around 10 GB, before the web UI answers a single request, and on a slow line that first start looks like a hung container for half an hour. With it, a three-language install is under 1 GB and up in a couple of minutes. The second thing to know is a quality verdict: the translations are fine for gist and for short UI strings, and noticeably below DeepL or Google on idiom and long sentences. Whether that matters depends on what you feed it.

What it actually is under the hood

LibreTranslate is a Flask API and a small web page wrapped around Argos Translate, which runs OpenNMT models through CTranslate2 on the CPU. No GPU is needed and none is used by default. Every language pair pivots through English, so Spanish to German is really Spanish to English to German, and the errors compound on the second hop. A single sentence takes on the order of a second on a modest CPU; a 200-word paragraph, a few seconds. It is the same engine behind the Argos desktop apps, with an HTTP interface and 16,285 GitHub stars' worth of integrations pointing at it.

The compose file, with the flag that matters

services:
  libretranslate:
    image: libretranslate/libretranslate:latest
    ports:
      - "5000:5000"
    environment:
      - LT_LOAD_ONLY=en,de,fr,es
      - LT_API_KEYS=true
      - LT_REQ_LIMIT=60
    volumes:
      - ./lt-models:/home/libretranslate/.local
    restart: unless-stopped

The volume matters as much as the flag: without it, every container recreation downloads the models again. LT_API_KEYS=true turns on per-key rate limiting, and keys are managed with the ltmanage command inside the container; LT_REQ_LIMIT is requests per minute per IP. Give it the 512 MB minimum plus roughly 200 to 400 MB per loaded language pair, and four languages stay comfortably under 2 GB.

Who calls it

The API is deliberately small: POST /translate with q, source, target and optionally format: html, plus /detect and /languages. That simplicity is why other self-hosted software supports it as a backend. Mastodon can use a LibreTranslate instance for its translate-post button, several browser extensions and mobile apps accept a custom endpoint, and it is a two-line call from anything in the self-hosted AI stack. Document translation of .txt, .odt, .docx and a few other formats works through /translate_file and the web UI. The web UI itself is a plain two-pane page with auto-detect, a swap button and a character counter tied to LT_CHAR_LIMIT, which is fine for pasting a paragraph and useless for a whole document; the API is what you are really deploying. Issue keys with ltmanage keys add 120 inside the container, where 120 is that key's requests per minute, and hand one key per client so a runaway browser extension cannot starve the rest. For a household that reads foreign-language articles and wants nothing sent to Google, it is enough.

Where a local LLM beats it, and where it doesn't

These days the honest competitor for a self-hoster is a local model in Ollama. A 7B or 8B instruction model translates the major European languages with better idiom than the Argos models, handles tone, and can be told to keep the Markdown intact. It also needs a GPU or a patient CPU, produces the occasional invented sentence, and gives you no language-detection endpoint. LibreTranslate wins on determinism, on running in 1 GB of RAM on an old NAS, on covering languages a small LLM handles badly, and on being a drop-in for software that already speaks its API. It loses on quality for anything a human will read carefully. Across the AI category it is the tool you keep for the API, not the one you pick for prose.

What I'd do

Run it with LT_LOAD_ONLY set to the four or five languages the household actually uses, a persistent models volume, API keys on, and no exposure beyond the LAN or a tailnet. Point Mastodon or the browser extension at it and forget it exists; it is one of the least maintenance-hungry services I run. For a translation someone will publish or send to a client, I paste into a local LLM instead and read the result twice. Keep both, expect neither to replace DeepL, and enjoy that nothing you translate leaves the house.