Slik selvhoster du LibreTranslate i 2026: Modeller, API-begrensninger og persistent data

Hvis du allerede har prøvd å selvhoste LibreTranslate, kjenner du sannsynligvis den frustrerende situasjonen: Grensesnittet vises, men modellene ble ikke lastet ned, eller et ønsket språkpar er utilgjengelig. Å opprette containeren på nytt løser sjelden uoverensstemmelser mellom URL-er, state og avhengigheter.

Denne gjennomgangen bruker ett konkret kriterium for å bekrefte at alt fungerer — vis installerte språk, oversett en fast setning i begge retninger, og test kvoter for API-nøkler og feilsvar. Hvert konfigurasjonsvalg vurderes opp mot dette kriteriet, ikke bare mot et grønt containermerke.

Gjenopprett LibreTranslate på en tom vert

List state før den første faktiske posten opprettes: nedlastede modeller, databasen for API-nøkler og egendefinert konfigurasjon. Monter /home/libretranslate/.local før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Bekreft monteringen ved å skrive ufarlige data, erstatte LibreTranslate og lese dataene tilbake.

Snapshots er nyttige for rask rollback, men du trenger en uavhengig sikkerhetskopi hvis verten eller volumet forsvinner. Gjenopprett til et tomt miljø med det låste imaget, og bekreft at modeller og state for API-nøkler kommer tilbake og at regresjonskorpuset fullføres med akseptabelt resultat. Bruk persistente volumer og snapshots for å holde disse to gjenopprettingsmekanismene adskilt.

Porter, prosesser og private tjenester

Ikke la LibreTranslate-imaget velge produksjonsarkitekturen ved et uhell. Imaget leverer en prosess på 5000; lagring, routing og eksterne krav trenger fortsatt bevisste livssykluser. Kravet til det lokale runtime-miljøet er lagring for nedlasting av modeller samt CPU eller GPU som passer til språkparene. Hold livssyklusen eksplisitt, slik at flytting av LibreTranslate mellom verter ikke endrer oppførselen i det stille.

Deployeringen er klar for grundigere testing når den kan vise installerte språk, oversette en fast setning i begge retninger og teste kvoter for API-nøkler og feilsvar. Følg transaksjonen i loggene, og følg med på innlastede språkmodeller, CPU-tid for inferens, parallelle forespørsler og diskplass brukt av modellnedlastinger. Disse observasjonene viser om den nåværende topologien isolerer riktig komponent.

Bekreft LibreTranslate-deployeringen fra ende til ende

En produksjonsport for LibreTranslate bør kunne kjøres av noen som ikke bygde deployeringen. Gi personen den låste versjonen, en ikke-sensitiv testkonto og denne oppgaven: vis installerte språk, oversett en fast setning i begge retninger, og test kvoter for API-nøkler og feilsvar. Hvis instruksjonene krever udokumentert shell-tilgang, er tjenesten ennå ikke operativt klar.

Gjenta testen etter å ha erstattet bare containeren. Gjenopprett deretter nedlastede modeller, databasen for API-nøkler og egendefinert konfigurasjon til tom infrastruktur, og bevis at modellene og state for API-nøkler kommer tilbake og at regresjonskorpuset fullføres med akseptabelt resultat. Mål innlastede språkmodeller, CPU-tid for inferens, parallelle forespørsler og diskplass brukt av modellnedlastinger under begge vellykkede kjøringer; uventede forskjeller avdekker ofte en manglende cache, indeks, worker eller datamontering.

Legg til en feilsimulering: send ufarlig input nær ressurs- eller formatgrensen som gjelder for denne grensen: modellene ble ikke lastet ned, eller et ønsket språkpar er utilgjengelig. LibreTranslate skal returnere en nyttig feil, bevare eksisterende state og gjenopprette normal drift når den gyldige betingelsen er tilbake. Lagre tidsstemplene og relevante logglinjer, med secrets maskert. Dette blir referansen for neste endring av image eller konfigurasjon.

Containerinnstillinger det er verdt å gjennomgå

Bruk en kommando som viser alle viktige valg. Denne grunnkonfigurasjonen binder LibreTranslate til loopback på verten, legger til de kjente datamonteringene og angir den første nødvendige innstillingen. Bekreft det lokale kravet før eksponering: lagring for nedlasting av modeller samt CPU eller GPU som passer til språkparene.

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

Bytt ut flytende tags med en testet versjon eller digest. Etter oppstart inspiserer du docker logs --tail 200 libretranslate og bekrefter at prosessen lytter på 5000. Kjør deretter LibreTranslate-akseptansetesten; et svar fra rotsiden kan ikke bevise at hele scenarioet fungerer: vis installerte språk, oversett en fast setning i begge retninger, og test kvoter for API-nøkler og feilsvar.

Credentials, roller og eksponerte flater

Den applikasjonsspesifikke sikkerhetsrisikoen er å kjøre et ubegrenset offentlig API som andre kan tappe for ressurser. Den operative løsningen er å aktivere API-nøkler eller autentisering oppstrøms, begrense hastigheten for offentlige kallere og installere bare nødvendige språkpar. Fullfør bootstrap via en begrenset rute, og fjern midlertidig tilgang til oppsett umiddelbart etterpå.

LT_API_KEYS styrer oppførselen, ikke konfidensialiteten; valider typen og verdien, og lagre faktiske LibreTranslate-credentials separat. Gi LibreTranslate-prosessen bare de dokumenterte monteringene og avhengighetsrutene; unngå tilgang til root på verten og Docker-socketen. Logg mislykket autentisering og konfigurasjonsfeil, men maskér tokens, connection strings og brukerinnhold.

Hold interne og eksterne URL-er adskilt

TLS-utstedelse er bare halve LibreTranslate-ruten. Server API-et via HTTPS og dokumenter riktig base path. Send trafikken internt til 5000, og videresend det eksterne scheme-et slik at genererte URL-er og sikre cookies forblir konsistente.

Bruk hele LibreTranslate-scenarioet fra et rent nettverk, ikke bare rotsiden. En 502-feil eller sertifikatfeil kan isoleres med automatisk oppsett av domene og TLS. Hvis trafikken når prosessen og modellene ikke ble lastet ned, eller et ønsket språkpar er utilgjengelig, diagnostiserer du denne tilstanden der den oppstår i stedet for å legge på flere redirects.

Feilsimuleringer for LibreTranslate

Kapasitetstester bør bruke innlastede språkmodeller, CPU-tid for inferens, parallelle forespørsler og diskplass brukt av modellnedlastinger — ikke en gjentatt forespørsel til /. Kjør scenarioet «vis installerte språk, oversett en fast setning i begge retninger, og test kvoter for API-nøkler og feilsvar» med realistisk samtidighet, og registrer svartid, feilrate og vekst i lagringsforbruket.

Oppgraderingsplanleggingen må ta høyde for denne risikoen: modellpakker og serverutgivelser kan endre oversettelsesresultatet, så vedlikehold et lite regresjonskorpus. Test den nye utgivelsen med representativ input, kjør deretter akseptansetransaksjonen på nytt og sammenlign resultatet. Hvis modellene ikke ble lastet ned, eller et ønsket språkpar er utilgjengelig, registrerer du den mislykkede transaksjonen og undersøker den første involverte grensen i stedet for å anta at ingressen er ansvarlig.

Deploy LibreTranslate på Dockup uten å miste grensene

En Dockup-mal bør angi imaget, port 5000, monteringer, helsesjekktiming, domene, TLS og levering av secrets. Dockup bør bevare LibreTranslate-runtime-innstillingene mens operatøren bekrefter dette lokale kravet: lagring for nedlasting av modeller samt CPU eller GPU som passer til språkparene. Den samme deployeringen kan målrettes mot Dockup-servere eller kapasitet koblet til av kunden.

Når ruten er aktiv, bruker du den offentlige innstillingen og prøver å vise installerte språk, oversette en fast setning i begge retninger og teste kvoter for API-nøkler og feilsvar. Ta sikkerhetskopi av nedlastede modeller, databasen for API-nøkler og egendefinert konfigurasjon, og ta med gjenopprettingsøvelsen i driftsplanen; dette er LibreTranslate-ansvar som fortsatt må være synlig etter at infrastrukturen er provisjonert.

Vanlige spørsmål

Hva trenger LibreTranslate for en produksjonsdeployering?

Rout LibreTranslate-containeren på port 5000 gjennom én HTTPS-origin. Kravet til det lokale runtime-miljøet er lagring for nedlasting av modeller samt CPU eller GPU som passer til språkparene. Ikke erklær LibreTranslate klar før du kan vise installerte språk, oversette en fast setning i begge retninger og teste kvoter for API-nøkler og feilsvar.

Hvilke LibreTranslate-data bør inngå i en sikkerhetskopi?

Gjør /home/libretranslate/.local persistent, og inkluder nedlastede modeller, databasen for API-nøkler og egendefinert konfigurasjon i det samme gjenopprettingsmanifestet. En ren LibreTranslate-gjenoppretting er bare vellykket når modellene og state for API-nøkler kommer tilbake og regresjonskorpuset fullføres med akseptabelt resultat.

Krever LibreTranslate HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige LibreTranslate-originen, og behold port 5000 på den interne ruten. Bruk LibreTranslate-innstillingen riktig: server API-et via HTTPS og dokumenter riktig base path. For LibreTranslate beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en LibreTranslate-oppgradering testes?

Gjenopprett gjeldende LibreTranslate-state i en isolert deployering, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at modellpakker og serverutgivelser kan endre oversettelsesresultatet, så vedlikehold et lite regresjonskorpus. Behold det forrige LibreTranslate-imaget til grensene for datamigrering og rollback er forstått.