Sådan selvhoster du LibreTranslate i 2026: Modeller, API-begrænsninger og vedvarende data

Hvis du allerede har forsøgt at selvhoste LibreTranslate, kender du sikkert den frustrerende situation: Brugergrænsefladen vises, men modellerne blev ikke downloadet, eller et ønsket sprogpar er ikke tilgængeligt. Det løser sjældent problemet at genskabe containeren, hvis der er uoverensstemmelse mellem URL'er, state og dependencies.

Denne gennemgang bruger ét konkret kriterium for, hvornår opsætningen er færdig — vis installerede sprog, oversæt en fast sætning i begge retninger, og afprøv API-key-kvote samt fejlresponser. Hvert konfigurationsvalg vurderes ud fra dette kriterium og ikke ud fra et grønt container-badge.

Gendan LibreTranslate på en tom host

Registrer state, før den første reelle post oprettes: downloadede modeller, API-key-database og brugerdefineret konfiguration. Mount /home/libretranslate/.local før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Bekræft mountet ved at skrive harmløse data, erstatte LibreTranslate og læse dem tilbage.

Snapshots er værdifulde til hurtig rollback, men der er brug for en uafhængig backup, hvis hosten eller volumen forsvinder. Gendan i et tomt miljø med det pinnede image, og verificer, at modeller og API-key-state kommer tilbage, og at regression corpus gennemføres med et acceptabelt resultat. Brug vedvarende volumes og snapshots for at holde de to recovery-mekanismer adskilt.

Porte, processer og private services

Lad ikke LibreTranslate-imaget ved et tilfælde bestemme produktionsarkitekturen. Imaget leverer en proces på 5000; storage, routing og eksterne krav kræver stadig bevidste lifecycles. Det lokale runtime-krav er storage til download af modeller samt CPU eller GPU, der passer til sprogparrene. Gør dets lifecycle eksplicit, så en flytning af LibreTranslate mellem hosts ikke ændrer funktionaliteten ubemærket.

Deploymentet er klar til mere omfattende test, når det kan vise installerede sprog, oversætte en fast sætning i begge retninger og afprøve API-key-kvote samt fejlresponser. Følg transaktionen i logs, og hold øje med indlæste sprogmodeller, CPU-inferencetid, parallelle requests og diskforbruget fra modeldownloads. Disse observationer viser, om den aktuelle topologi isolerer den rigtige komponent.

Bevis, at LibreTranslate-deploymentet fungerer fra ende til anden

En produktionsgate for LibreTranslate bør kunne udføres af en person, der ikke byggede deploymentet. Giv personen den pinnede version, en ikke-følsom testkonto og denne opgave: Vis installerede sprog, oversæt en fast sætning i begge retninger, og afprøv API-key-kvote samt fejlresponser. Hvis instruktionerne kræver udokumenteret shell-adgang, er servicen endnu ikke driftsklar.

Gentag testen efter kun at have udskiftet containeren. Gendan derefter downloadede modeller, API-key-database og brugerdefineret konfiguration i blank infrastruktur, og bevis, at modeller og API-key-state kommer tilbage, og at regression corpus gennemføres med et acceptabelt resultat. Mål indlæste sprogmodeller, CPU-inferencetid, parallelle requests og diskforbruget fra modeldownloads under begge vellykkede kørsler; uventede forskelle afslører ofte en manglende cache, et manglende index, en worker eller et manglende data-mount.

Tilføj en failure drill: Send harmløst input tæt på den ressource- eller formatgrænse, der er knyttet til denne situation: modeller blev ikke downloadet, eller et ønsket sprogpar er ikke tilgængeligt. LibreTranslate bør udsende en brugbar fejl, bevare eksisterende state og komme sig, når den gyldige betingelse vender tilbage. Gem tidsstemplerne og de relevante loglinjer, og redigér secrets væk. Disse oplysninger bliver referencepunktet for den næste ændring af image eller konfiguration.

Containerindstillinger, der er værd at gennemgå

Brug en kommando, der eksponerer alle vigtige valg. Denne baseline binder LibreTranslate til hostens loopback, tilføjer de kendte data-mounts og angiver den første nødvendige indstilling. Bekræft det lokale krav, før servicen eksponeres: storage til download af modeller samt CPU eller GPU, der passer til sprogparrene.

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

Erstat floating tags med en testet version eller digest. Efter opstart skal du inspicere docker logs --tail 200 libretranslate og bekræfte, at processen lytter på 5000. Udfør derefter LibreTranslates acceptancetest; et svar fra root-siden kan ikke bevise, at hele scenariet lykkes: Vis installerede sprog, oversæt en fast sætning i begge retninger, og afprøv API-key-kvote samt fejlresponser.

Credentials, roller og eksponerede overflader

Den applikationsspecifikke sikkerhedsrisiko er at køre et ubegrænset offentligt API, som andre kan dræne. Den operationelle løsning er at aktivere API keys eller upstream-authentication, rate-limite offentlige clients og kun installere de nødvendige sprogpar. Gennemfør bootstrap via en begrænset route, og fjern straks den midlertidige setup-adgang bagefter.

LT_API_KEYS styrer funktionalitet frem for confidentiality; verificer dens type og værdi, og opbevar ægte LibreTranslate-credentials separat. Giv LibreTranslate-processen kun de dokumenterede mounts og dependency-routes, og undgå adgang til hostens root og Docker socket. Log mislykket authentication og konfigurationsfejl, men redigér tokens, connection strings og brugerindhold væk.

Hold interne og eksterne URL'er adskilt

TLS-udstedelse er kun halvdelen af LibreTranslate-routen. Servér API'et via HTTPS, og dokumentér den korrekte base path. Send trafik internt til 5000, og videresend det eksterne scheme, så genererede URL'er og secure cookies forbliver konsistente.

Brug det komplette LibreTranslate-scenarie fra et rent netværk, ikke kun root-siden. En 502- eller certifikatfejl kan isoleres med automatisk domain- og TLS-opsætning. Hvis trafikken når processen, og modellerne ikke blev downloadet, eller et ønsket sprogpar ikke er tilgængeligt, skal du diagnosticere betingelsen dér, hvor den opstår, i stedet for at stable redirects oven på hinanden.

Failure drills for LibreTranslate

Kapacitetstests bør afprøve indlæste sprogmodeller, CPU-inferencetid, parallelle requests og diskforbruget fra modeldownloads — ikke en gentaget request til /. Kør scenariet “vis installerede sprog, oversæt en fast sætning i begge retninger, og afprøv API-key-kvote samt fejlresponser” med realistisk concurrency, og registrér latency, fejlrate og vækst i storage.

Opgraderingsplanlægningen skal tage højde for denne risiko: Modelpakker og serverudgivelser kan ændre oversættelsesresultatet, så vedligehold et lille regression corpus. Test den nye release med repræsentativt input, gentag derefter acceptancetransaktionen, og sammenlign resultatet. Hvis modellerne ikke blev downloadet, eller et ønsket sprogpar ikke er tilgængeligt, skal du registrere den fejlslagne transaktion og undersøge den første involverede boundary i stedet for at antage, at ingressen er ansvarlig.

Deploy LibreTranslate på Dockup uden at miste dets afgrænsninger

En Dockup-template bør indeholde image, port 5000, mounts, health-timing, domain, TLS og levering af secrets. Dockup bør bevare LibreTranslates runtime-indstillinger, mens operatoren bekræfter dette lokale krav: storage til download af modeller samt CPU eller GPU, der passer til sprogparrene. Det samme deployment kan målrettes Dockup-servere eller kundetilknyttet kapacitet.

Når routen er live, skal du anvende den offentlige indstilling og forsøge at vise installerede sprog, oversætte en fast sætning i begge retninger og afprøve API-key-kvote samt fejlresponser. Tag backup af downloadede modeller, API-key-database og brugerdefineret konfiguration, og behold restore-øvelsen i driftsplanen; det er LibreTranslate-ansvar, som fortsat skal være synligt efter provisionering af infrastrukturen.

Ofte stillede spørgsmål

Hvad har LibreTranslate brug for i et produktionsdeployment?

Route LibreTranslate-containeren på port 5000 gennem én HTTPS-origin. Det lokale runtime-krav er storage til download af modeller samt CPU eller GPU, der passer til sprogparrene. Erklær ikke LibreTranslate klar, før du kan vise installerede sprog, oversætte en fast sætning i begge retninger og afprøve API-key-kvote samt fejlresponser.

Hvilke LibreTranslate-data skal med i en backup?

Gør /home/libretranslate/.local persistent, og medtag downloadede modeller, API-key-database og brugerdefineret konfiguration i det samme recovery-manifest. En ren LibreTranslate-restore lykkes kun, når modeller og API-key-state kommer tilbage, og regression corpus gennemføres med et acceptabelt resultat.

Kræver LibreTranslate HTTPS bag en reverse proxy?

Brug HTTPS for den offentlige LibreTranslate-origin, og behold port 5000 på den interne route. Anvend LibreTranslate-indstillingen korrekt: Servér API'et via HTTPS, og dokumentér den korrekte base path. For LibreTranslate beskytter HTTPS credentials eller brugerindhold under transport og sørger for, at origin-følsom klientadfærd forbliver konsistent.

Hvordan bør en LibreTranslate-opgradering testes?

Gendan den aktuelle LibreTranslate-state i et isoleret deployment, anvend kandidatversionen, og gentag acceptancetransaktionen. Vær særligt opmærksom, fordi modelpakker og serverudgivelser kan ændre oversættelsesresultatet, så vedligehold et lille regression corpus. Behold det tidligere LibreTranslate-image, indtil grænsen for datamigrering og rollback er forstået.