LibreTranslate zelf hosten in 2026: modellen, API-limieten en persistente data

Als je LibreTranslate al eens zelf hebt gehost, herken je deze frustrerende situatie waarschijnlijk: de UI verschijnt, maar modellen zijn niet gedownload of een aangevraagd talenpaar is niet beschikbaar. De container opnieuw aanmaken lost een verschil tussen URL's, state en dependencies zelden op.

Deze walkthrough gebruikt één concreet criterium voor een geslaagde oplevering: geïnstalleerde talen weergeven, een vaste zin in beide richtingen vertalen en API-keyquota en foutmeldingen testen. Elke configuratiekeuze wordt aan dat criterium getoetst, niet aan een groen containerbadge.

LibreTranslate herstellen op een lege host

Breng de state in kaart voordat het eerste echte record wordt aangemaakt: gedownloade modellen, de API-keydatabase en aangepaste configuratie. Mount /home/libretranslate/.local vóór de bootstrap, schrijf ongevaarlijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Bevestig de mount door ongevaarlijke data te schrijven, LibreTranslate te vervangen en die data opnieuw uit te lezen.

Snapshots zijn waardevol voor snel terugdraaien, maar er is een onafhankelijke back-up nodig wanneer de host of het volume verdwijnt. Herstel naar een lege omgeving met de vastgezette image en controleer of de modellen en API-keystate terugkomen en de regressiecorpus met acceptabele uitvoer wordt verwerkt. Gebruik persistente volumes en snapshots om deze twee herstelmechanismen van elkaar gescheiden te houden.

Poorten, processen en private services

Laat de LibreTranslate-image niet per ongeluk de productionarchitectuur bepalen. De image levert een proces op 5000; opslag, routing en externe vereisten hebben nog steeds bewust beheerde lifecycles nodig. De vereiste voor de lokale runtime is opslag voor het downloaden van modellen en CPU of GPU die geschikt is voor de talenparen. Houd de lifecycle expliciet, zodat het verplaatsen van LibreTranslate tussen hosts niet ongemerkt het gedrag verandert.

De deployment is klaar voor diepgaandere tests wanneer geïnstalleerde talen kunnen worden weergegeven, een vaste zin in beide richtingen kan worden vertaald en API-keyquota en foutmeldingen kunnen worden getest. Volg de transactie in de logs en houd geladen taalmodellen, CPU-inferentietijd, parallelle requests en de schijfruimte die door modeldownloads wordt gebruikt in de gaten. Deze observaties laten zien of de huidige topologie het juiste component isoleert.

Bewijs de LibreTranslate-deployment end-to-end

Een production gate voor LibreTranslate moet uitvoerbaar zijn door iemand die de deployment niet heeft gebouwd. Geef die persoon de vastgezette versie, een niet-gevoelig testaccount en deze taak: geïnstalleerde talen weergeven, een vaste zin in beide richtingen vertalen en API-keyquota en foutmeldingen testen. Als voor de instructies ongedocumenteerde shelltoegang nodig is, is de service operationeel nog niet klaar.

Herhaal de gate nadat alleen de container is vervangen. Herstel vervolgens de gedownloade modellen, de API-keydatabase en de aangepaste configuratie naar lege infrastructuur en bewijs dat de modellen en API-keystate terugkomen en de regressiecorpus met acceptabele uitvoer wordt verwerkt. Meet tijdens beide geslaagde runs de geladen taalmodellen, CPU-inferentietijd, parallelle requests en de schijfruimte die door modeldownloads wordt gebruikt; onverwachte verschillen wijzen vaak op een ontbrekende cache, index, worker of datamount.

Voeg een failure drill toe: stuur ongevaarlijke input in de buurt van de resource- of formaatslimiet die bij deze grens hoort: modellen zijn niet gedownload of een aangevraagd talenpaar is niet beschikbaar. LibreTranslate moet een bruikbare foutmelding geven, bestaande state behouden en herstellen zodra de geldige situatie terugkeert. Sla de tijdstippen en relevante logregels op, waarbij secrets worden verwijderd. Dit bewijsmateriaal wordt de referentie voor de volgende image- of configuratiewijziging.

Containerinstellingen die je moet controleren

Gebruik een command waarmee elke belangrijke keuze zichtbaar wordt. Deze baseline bindt LibreTranslate aan de loopback van de host, voegt de bekende datamounts toe en levert de eerste vereiste instelling. Bevestig de vereiste voor de lokale runtime voordat je de service blootstelt: opslag voor het downloaden van modellen en CPU of GPU die geschikt is voor de talenparen.

docker run -d \
  --name libretranslate \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v libretranslate-data:/home/libretranslate/.local \
  -e LT_API_KEYS=true \
  libretranslate/libretranslate:latest

Vervang floating tags door een geteste versie of digest. Controleer na het opstarten docker logs --tail 200 libretranslate en bevestig dat het proces op 5000 luistert. Voer daarna de acceptatietest van LibreTranslate uit; een response van de rootpagina bewijst niet dat het volledige scenario slaagt: geïnstalleerde talen weergeven, een vaste zin in beide richtingen vertalen en API-keyquota en foutmeldingen testen.

Credentials, rollen en blootgestelde oppervlakken

Het specifieke securityrisico van de applicatie is een onbeperkte publieke API die anderen kunnen leegtrekken. Het operationele antwoord is API-keys of upstream-authenticatie inschakelen, publieke callers rate-limiten en alleen de benodigde talenparen installeren. Voltooi de bootstrap via een beperkte route en verwijder tijdelijke setup-toegang direct daarna.

LT_API_KEYS bepaalt het gedrag en niet de vertrouwelijkheid; valideer het type en de waarde ervan en sla echte LibreTranslate-credentials afzonderlijk op. Geef het LibreTranslate-proces alleen de gedocumenteerde mounts en dependency-routes; vermijd toegang tot de root van de host en tot de Docker-socket. Log mislukte authenticatie en configuratiefouten, maar redigeer tokens, connection strings en gebruikerscontent.

Houd interne en externe URL's uit elkaar

Het uitgeven van TLS is slechts de helft van de LibreTranslate-route. Bied de API aan via HTTPS en documenteer het juiste base path. Stuur verkeer intern naar 5000 en geef het externe scheme door, zodat gegenereerde URL's en secure cookies consistent blijven.

Gebruik het volledige LibreTranslate-scenario vanaf een schoon netwerk, niet alleen de rootpagina. Een 502- of certificaatfout kun je isoleren met automatische domein- en TLS-configuratie. Als het verkeer het proces bereikt en modellen niet zijn gedownload of een aangevraagd talenpaar niet beschikbaar is, diagnoseer je die toestand op de plek waar die optreedt in plaats van redirects op elkaar te stapelen.

Failure drills voor LibreTranslate

Capacitytests moeten geladen taalmodellen, CPU-inferentietijd, parallelle requests en de schijfruimte die door modeldownloads wordt gebruikt testen, niet een herhaald request naar /. Voer het scenario “geïnstalleerde talen weergeven, een vaste zin in beide richtingen vertalen en API-keyquota en foutmeldingen testen” uit met een realistische concurrency en leg latency, foutpercentage en opslaggroei vast.

Bij upgradeplanning moet je rekening houden met dit risico: modelpackages en serverreleases kunnen de vertaaluitvoer wijzigen, dus houd een kleine regressiecorpus bij. Test de nieuwe release met representatieve input, herhaal daarna de acceptatietransactie en vergelijk het resultaat. Als modellen niet zijn gedownload of een aangevraagd talenpaar niet beschikbaar is, leg je de mislukte transactie vast en inspecteer je de eerste betrokken grens in plaats van aan te nemen dat ingress de oorzaak is.

LibreTranslate op Dockup deployen zonder de grenzen ervan te verliezen

Een Dockup-template moet de image, poort 5000, mounts, healthtiming, het domein, TLS en secret-delivery vastleggen. Dockup moet de runtime-instellingen van LibreTranslate behouden, terwijl de operator deze vereiste voor de lokale runtime bevestigt: opslag voor het downloaden van modellen en CPU of GPU die geschikt is voor de talenparen. Dezelfde deployment kan gericht zijn op Dockup-servers of capaciteit die door de klant is gekoppeld.

Nadat de route actief is, pas je de publieke instelling toe en probeer je geïnstalleerde talen weer te geven, een vaste zin in beide richtingen te vertalen en API-keyquota en foutmeldingen te testen. Maak back-ups van gedownloade modellen, de API-keydatabase en de aangepaste configuratie en houd de restore-oefening in het operationele plan; dit zijn verantwoordelijkheden van LibreTranslate die ook na het provisionen van de infrastructuur zichtbaar blijven.

Veelgestelde vragen

Wat heeft LibreTranslate nodig voor een productiondeployment?

Route de LibreTranslate-container op poort 5000 via één HTTPS-origin. De vereiste voor de lokale runtime is opslag voor het downloaden van modellen en CPU of GPU die geschikt is voor de talenparen. Markeer LibreTranslate pas als klaar wanneer je geïnstalleerde talen kunt weergeven, een vaste zin in beide richtingen kunt vertalen en API-keyquota en foutmeldingen kunt testen.

Welke LibreTranslate-data hoort in een back-up?

Maak /home/libretranslate/.local persistent en neem gedownloade modellen, de API-keydatabase en de aangepaste configuratie op in hetzelfde recoverymanifest. Een schone LibreTranslate-restore is alleen geslaagd wanneer de modellen en API-keystate terugkomen en de regressiecorpus met acceptabele uitvoer wordt verwerkt.

Heeft LibreTranslate HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke LibreTranslate-origin en houd poort 5000 op de interne route. Pas de LibreTranslate-instelling correct toe: bied de API aan via HTTPS en documenteer het juiste base path. Voor LibreTranslate beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origin-gevoelig clientgedrag consistent blijft.

Hoe test je een LibreTranslate-upgrade?

Herstel de huidige LibreTranslate-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat modelpackages en serverreleases de vertaaluitvoer kunnen wijzigen; houd daarom een kleine regressiecorpus bij. Bewaar de vorige LibreTranslate-image totdat de grenzen van de datamigratie en rollback duidelijk zijn.