Så kör du LibreTranslate själv 2026: modeller, API-gränser och beständiga data

Om du redan har försökt köra LibreTranslate själv känner du förmodligen igen det frustrerande läget: gränssnittet visas, men modellerna har inte laddats ned eller så är det begärda språkparet inte tillgängligt. Att återskapa containern löser sällan en konflikt mellan URL:er, state och dependencies.

Den här genomgången använder ett konkret kriterium för att anse installationen klar – lista installerade språk, översätt en fast mening i båda riktningarna och testa API-nyckelns kvotgräns och felsvar. Varje konfigurationsval bedöms utifrån det kriteriet, inte utifrån en grön containerbadge.

Återställ LibreTranslate på en tom värd

Lista state innan den första riktiga posten skapas: nedladdade modeller, databasen för API-nycklar och anpassad konfiguration. Montera /home/libretranslate/.local före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. Bekräfta monteringen genom att skriva ofarliga data, ersätta LibreTranslate och läsa tillbaka dem.

Snapshots är värdefulla för snabb rollback, men du behöver en separat säkerhetskopia om värden eller volymen försvinner. Återställ till en tom miljö med den fixerade imagen och verifiera att modellerna och API-nyckelns state kommer tillbaka och att regressionstestsviten slutförs med godtagbart resultat. Använd beständiga volymer och snapshots för att hålla isär de två återställningsmekanismerna.

Portar, processer och privata tjänster

Låt inte LibreTranslate-imagen av misstag bestämma produktionsarkitekturen. Imagen tillhandahåller en process på port 5000; lagring, routing och externa krav behöver fortfarande ha medvetna livscykler. Det lokala runtime-kravet är lagring för nedladdning av modeller samt CPU eller GPU som passar språkparen. Håll dess livscykel explicit så att en flytt av LibreTranslate mellan värdar inte i tysthet ändrar beteendet.

Distributionen är redo för djupare tester när den kan lista installerade språk, översätta en fast mening i båda riktningarna och testa API-nyckelns kvotgräns och felsvar. Följ transaktionen i loggarna och övervaka inlästa språkmodeller, CPU-tid för inferens, parallella requests och diskutrymme som används av modellnedladdningar. Dessa observationer visar om den aktuella topologin isolerar rätt komponent.

Verifiera LibreTranslate-distributionen från början till slut

En produktionsgrind för LibreTranslate ska kunna köras av någon som inte byggde distributionen. Ge personen den fixerade versionen, ett testkonto utan känsliga uppgifter och följande uppgift: lista installerade språk, översätt en fast mening i båda riktningarna och testa API-nyckelns kvotgräns och felsvar. Om instruktionerna kräver odokumenterad shellåtkomst är tjänsten ännu inte driftmässigt redo.

Upprepa grinden efter att endast containern har ersatts. Återställ sedan nedladdade modeller, API-nyckeldatabasen och den anpassade konfigurationen till en tom infrastruktur och bevisa att modellerna och API-nyckelns state kommer tillbaka och att regressionstestsviten slutförs med godtagbart resultat. Mät inlästa språkmodeller, CPU-tid för inferens, parallella requests och diskutrymme som används av modellnedladdningar under båda lyckade körningarna; oväntade skillnader avslöjar ofta en saknad cache, ett saknat index, en saknad worker eller en saknad datamontering.

Lägg till en felövning: skicka ofarlig input nära resurs- eller formatgränsen som hör ihop med detta scenario: modellerna har inte laddats ned eller det begärda språkparet är inte tillgängligt. LibreTranslate ska returnera ett användbart fel, bevara befintligt state och återhämta sig när det giltiga villkoret åter gäller. Spara tidsstämplar och relevanta loggrader, med secrets maskerade. Det bevismaterialet blir referens för nästa image- eller konfigurationsändring.

Containerinställningar värda att granska

Använd ett kommando som visar alla viktiga val. Den här baslinjen binder LibreTranslate till värdens loopback, lägger till de kända datamonteringarna och anger den första nödvändiga inställningen. Bekräfta det lokala kravet innan exponering: lagring för nedladdning av modeller samt CPU eller GPU som passar språkparen.

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

Ersätt flytande taggar med en testad version eller digest. Inspektera docker logs --tail 200 libretranslate efter starten och bekräfta att processen lyssnar på port 5000. Kör sedan LibreTranslates acceptanstest; ett svar från root-sidan kan inte bevisa att hela scenariot lyckas: lista installerade språk, översätt en fast mening i båda riktningarna och testa API-nyckelns kvotgräns och felsvar.

Credentials, roller och exponerade ytor

Den applikationsspecifika säkerhetsrisken är att köra ett obegränsat publikt API som andra kan tömma på resurser. Det operativa svaret är att aktivera API-nycklar eller autentisering uppströms, införa rate limiting för publika anropare och endast installera de språkpar som behövs. Slutför bootstrap via en begränsad route och ta omedelbart bort tillfällig setup-åtkomst därefter.

LT_API_KEYS styr beteendet, inte konfidentialiteten; validera dess typ och värde och lagra riktiga LibreTranslate-credentials separat. Ge LibreTranslate-processen endast de dokumenterade monteringspunkterna och dependency-routes; undvik åtkomst till värdens root och Docker-socketen. Logga misslyckad autentisering och konfigurationsfel, men maskera tokens, connection strings och användarinnehåll.

Håll interna och externa URL:er isär

Utfärdande av TLS är bara halva LibreTranslate-routen. Servera API:t via HTTPS och dokumentera den korrekta base path. Skicka trafik internt till port 5000 och vidarebefordra det externa schemat så att genererade URL:er och säkra cookies förblir konsekventa.

Använd hela LibreTranslate-scenariot från ett rent nätverk, inte bara root-sidan. Ett 502-fel eller certifikatfel kan isoleras med automatisk domän- och TLS-konfiguration. Om trafiken når processen och modellerna inte har laddats ned eller det begärda språkparet inte är tillgängligt ska du diagnostisera det villkoret där det uppstår i stället för att lägga på fler redirects.

Felövningar för LibreTranslate

Kapacitetstester ska belasta inlästa språkmodeller, CPU-tid för inferens, parallella requests och diskutrymme som används av modellnedladdningar – inte skicka upprepade requests till /. Kör scenariot ”lista installerade språk, översätt en fast mening i båda riktningarna och testa API-nyckelns kvotgräns och felsvar” med realistisk samtidighet och registrera svarstid, felfrekvens och lagringstillväxt.

Planeringen av uppgraderingar måste ta hänsyn till följande risk: modellpaket och serverreleaser kan ändra översättningsresultatet, så underhåll en liten regressionstestsvit. Testa den nya releasen med representativ input, upprepa sedan acceptanstransaktionen och jämför resultatet. Om modellerna inte har laddats ned eller det begärda språkparet inte är tillgängligt ska du fånga den misslyckade transaktionen och undersöka den första berörda gränsen i stället för att anta att ingressen är ansvarig.

Distribuera LibreTranslate på Dockup utan att förlora dess gränser

En Dockup-mall bör koda imagen, port 5000, monteringar, health timing, domän, TLS och leverans av secrets. Dockup bör bevara LibreTranslates runtime-inställningar medan operatören bekräftar det här lokala kravet: lagring för nedladdning av modeller samt CPU eller GPU som passar språkparen. Samma distribution kan köras på Dockup-servrar eller kundansluten kapacitet.

När routen är aktiv aktiverar du den publika inställningen och försöker lista installerade språk, översätta en fast mening i båda riktningarna samt testa API-nyckelns kvotgräns och felsvar. Säkerhetskopiera nedladdade modeller, API-nyckeldatabasen och den anpassade konfigurationen och behåll återställningsövningen i driftplanen; detta är LibreTranslate-ansvar som förblir synligt efter infrastrukturtillhandahållandet.

Vanliga frågor

Vad behöver LibreTranslate för en produktionsdistribution?

Routa LibreTranslate-containern på port 5000 via en HTTPS-origin. Det lokala runtime-kravet är lagring för nedladdning av modeller samt CPU eller GPU som passar språkparen. Anse inte LibreTranslate vara redo förrän du kan lista installerade språk, översätta en fast mening i båda riktningarna och testa API-nyckelns kvotgräns och felsvar.

Vilka LibreTranslate-data ska ingå i en säkerhetskopia?

Gör /home/libretranslate/.local beständig och inkludera nedladdade modeller, API-nyckeldatabasen och den anpassade konfigurationen i samma återställningsmanifest. En ren LibreTranslate-återställning är endast godkänd när modellerna och API-nyckelns state kommer tillbaka och regressionstestsviten slutförs med godtagbart resultat.

Kräver LibreTranslate HTTPS bakom en reverse proxy?

Använd HTTPS för den publika LibreTranslate-originen och behåll port 5000 på den interna routen. Tillämpa LibreTranslate-inställningen korrekt: servera API:t via HTTPS och dokumentera den korrekta base path. För LibreTranslate skyddar HTTPS credentials och användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en LibreTranslate-uppgradering testas?

Återställ aktuellt LibreTranslate-state i en isolerad distribution, tillämpa kandidatversionen och upprepa acceptanstransaktionen. Var särskilt uppmärksam eftersom modellpaket och serverreleaser kan ändra översättningsresultatet, så underhåll en liten regressionstestsvit. Behåll den tidigare LibreTranslate-imagen tills gränsen för datamigrering och rollback är förstådd.