LibreTranslate 2026 selbst hosten: Modelle, API-Limits und persistente Daten
LibreTranslate mit korrekten Ports, persistentem Speicher, HTTPS, Secrets, Backups und Upgrade-Prüfungen selbst hosten. Erfahren Sie, wie Sie das Problem beheben, wenn Modelle nicht heruntergeladen wurden.
Wenn Sie bereits versucht haben, LibreTranslate selbst zu hosten, kennen Sie wahrscheinlich diesen frustrierenden Zustand: Die Benutzeroberfläche wird angezeigt, aber Modelle wurden nicht heruntergeladen oder ein angefordertes Sprachpaar ist nicht verfügbar. Das erneute Erstellen des Containers behebt eine Abweichung zwischen URLs, Zustand und Abhängigkeiten nur selten.
Dieser Leitfaden verwendet ein konkretes Abnahmekriterium: installierte Sprachen auflisten, einen festen Satz in beide Richtungen übersetzen sowie API-Key-Kontingent und Fehlerantworten prüfen. Jede Konfigurationsentscheidung wird an diesem Kriterium gemessen und nicht an einem grünen Container-Badge.
LibreTranslate auf einem leeren Host wiederherstellen
Listen Sie den Zustand auf, bevor der erste echte Datensatz erstellt wird: heruntergeladene Modelle, API-Key-Datenbank und benutzerdefinierte Konfiguration. Binden Sie /home/libretranslate/.local vor dem Bootstrap ein, schreiben Sie harmlose Beispieldaten und ersetzen Sie den Container, um nachzuweisen, dass dieser Pfad tatsächlich persistent ist. Bestätigen Sie das Mount, indem Sie harmlose Daten schreiben, LibreTranslate ersetzen und die Daten anschließend wieder auslesen.
Snapshots sind für ein schnelles Rollback wertvoll. Wenn der Host oder das Volume jedoch verschwindet, benötigen Sie ein unabhängiges Backup. Stellen Sie die Daten in einer leeren Umgebung mit dem festgelegten Image wieder her und prüfen Sie, ob Modelle und API-Key-Zustand zurückkehren und der Regressionstest mit akzeptablen Ergebnissen abgeschlossen wird. Nutzen Sie persistente Volumes und Snapshots, um diese beiden Wiederherstellungsmechanismen getrennt zu halten.
Ports, Prozesse und private Services
Lassen Sie nicht zu, dass das LibreTranslate-Image versehentlich die Produktionsarchitektur vorgibt. Das Image stellt einen Prozess auf Port 5000 bereit; Speicher, Routing und externe Anforderungen benötigen weiterhin bewusst definierte Lebenszyklen. Die lokale Laufzeitanforderung umfasst Speicher für Modelldownloads sowie eine für die Sprachpaare geeignete CPU oder GPU. Halten Sie den Lebenszyklus explizit, damit das Verschieben von LibreTranslate zwischen Hosts das Verhalten nicht unbemerkt verändert.
Die Bereitstellung ist bereit für weitergehende Tests, wenn sie installierte Sprachen auflisten, einen festen Satz in beide Richtungen übersetzen sowie API-Key-Kontingent und Fehlerantworten prüfen kann. Verfolgen Sie die Transaktion in den Logs und beobachten Sie geladene Sprachmodelle, CPU-Inferenzzeit, parallele Anfragen und den von Modelldownloads belegten Speicherplatz. Diese Beobachtungen zeigen, ob die aktuelle Topologie die richtige Komponente isoliert.
Die LibreTranslate-Bereitstellung vollständig prüfen
Ein Produktions-Gate für LibreTranslate sollte von einer Person ausführbar sein, die die Bereitstellung nicht erstellt hat. Geben Sie dieser Person die festgelegte Version, ein nicht sensibles Testkonto und diese Aufgabe: installierte Sprachen auflisten, einen festen Satz in beide Richtungen übersetzen sowie API-Key-Kontingent und Fehlerantworten prüfen. Wenn die Anleitung undokumentierten Shell-Zugriff erfordert, ist der Service operativ noch nicht bereit.
Wiederholen Sie das Gate, nachdem Sie ausschließlich den Container ersetzt haben. Stellen Sie anschließend heruntergeladene Modelle, die API-Key-Datenbank und die benutzerdefinierte Konfiguration in einer leeren Infrastruktur wieder her und weisen Sie nach, dass Modelle und API-Key-Zustand zurückkehren und der Regressionstest mit akzeptablen Ergebnissen abgeschlossen wird. Messen Sie während beider erfolgreichen Durchläufe geladene Sprachmodelle, CPU-Inferenzzeit, parallele Anfragen und den von Modelldownloads belegten Speicherplatz. Unerwartete Unterschiede weisen häufig auf einen fehlenden Cache, Index, Worker oder Daten-Mount hin.
Fügen Sie einen Fehler-Drill hinzu: Senden Sie harmlose Eingaben nahe am für diese Grenze relevanten Ressourcen- oder Formatlimit: Modelle wurden nicht heruntergeladen oder ein angefordertes Sprachpaar ist nicht verfügbar. LibreTranslate sollte eine hilfreiche Fehlermeldung ausgeben, den bestehenden Zustand bewahren und sich erholen, sobald die gültige Bedingung wiederhergestellt ist. Speichern Sie Zeitstempel und relevante Logzeilen und entfernen Sie dabei Secrets. Diese Belege dienen als Referenz für die nächste Änderung am Image oder an der Konfiguration.
Container-Einstellungen, die Sie prüfen sollten
Verwenden Sie einen Befehl, der jede wichtige Entscheidung sichtbar macht. Diese Basiskonfiguration bindet LibreTranslate an das Loopback-Interface des Hosts, fügt die bekannten Daten-Mounts hinzu und setzt die erste erforderliche Einstellung. Bestätigen Sie die lokale Anforderung vor der Veröffentlichung: Speicher für Modelldownloads sowie eine für die Sprachpaare geeignete CPU oder GPU.
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
Ersetzen Sie frei bewegliche Tags durch eine getestete Version oder einen Digest. Prüfen Sie nach dem Start docker logs --tail 200 libretranslate und bestätigen Sie, dass der Prozess auf Port 5000 lauscht. Führen Sie anschließend die Abnahmeaktion für LibreTranslate aus. Eine Antwort auf der Root-Seite kann nicht nachweisen, dass das vollständige Szenario erfolgreich ist: installierte Sprachen auflisten, einen festen Satz in beide Richtungen übersetzen sowie API-Key-Kontingent und Fehlerantworten prüfen.
Zugangsdaten, Rollen und exponierte Oberflächen
Das anwendungsspezifische Sicherheitsrisiko besteht darin, eine unbegrenzte öffentliche API zu betreiben, die andere vollständig ausschöpfen können. Die betriebliche Lösung besteht darin, API-Keys oder eine vorgelagerte Authentifizierung zu aktivieren, öffentliche Aufrufer per Rate Limiting zu begrenzen und nur die erforderlichen Sprachpaare zu installieren. Schließen Sie den Bootstrap über eine eingeschränkte Route ab und entfernen Sie den temporären Setup-Zugriff unmittelbar danach.
LT_API_KEYS steuert das Verhalten, nicht die Vertraulichkeit. Prüfen Sie Typ und Wert und speichern Sie echte LibreTranslate-Zugangsdaten getrennt. Geben Sie dem LibreTranslate-Prozess nur seine dokumentierten Mounts und Abhängigkeitsrouten. Vermeiden Sie Zugriff auf das Root-Dateisystem des Hosts und auf den Docker-Socket. Protokollieren Sie fehlgeschlagene Authentifizierungen und Konfigurationsfehler, redigieren Sie jedoch Tokens, Verbindungszeichenfolgen und Benutzerinhalte.
Interne und externe URLs korrekt auseinanderhalten
Die Ausstellung von TLS-Zertifikaten ist nur die Hälfte der LibreTranslate-Route. Stellen Sie die API über HTTPS bereit und dokumentieren Sie den korrekten Basispfad. Leiten Sie den Datenverkehr intern an Port 5000 weiter und übergeben Sie das externe Schema, damit generierte URLs und sichere Cookies konsistent bleiben.
Verwenden Sie das vollständige LibreTranslate-Szenario aus einem sauberen Netzwerk und nicht nur die Root-Seite. Ein 502-Fehler oder ein Zertifikatsfehler lässt sich mit automatischer Domain- und TLS-Einrichtung isolieren. Wenn der Datenverkehr den Prozess erreicht, aber Modelle nicht heruntergeladen wurden oder ein angefordertes Sprachpaar nicht verfügbar ist, diagnostizieren Sie diese Bedingung dort, wo sie auftritt, statt weitere Redirects zu stapeln.
Fehler-Drills für LibreTranslate
Kapazitätstests sollten geladene Sprachmodelle, CPU-Inferenzzeit, parallele Anfragen und den von Modelldownloads belegten Speicherplatz prüfen, nicht wiederholte Anfragen an /. Führen Sie das Szenario „installierte Sprachen auflisten, einen festen Satz in beide Richtungen übersetzen sowie API-Key-Kontingent und Fehlerantworten prüfen“ mit realistischer Parallelität aus und erfassen Sie Latenz, Fehlerrate und Speicherwachstum.
Die Upgrade-Planung muss dieses Risiko berücksichtigen: Modellpakete und Server-Releases können das Übersetzungsergebnis verändern. Pflegen Sie daher einen kleinen Regressionstest. Testen Sie das neue Release mit repräsentativen Eingaben, wiederholen Sie anschließend die Abnahmetransaktion und vergleichen Sie das Ergebnis. Wenn Modelle nicht heruntergeladen wurden oder ein angefordertes Sprachpaar nicht verfügbar ist, erfassen Sie die fehlschlagende Transaktion und untersuchen Sie die erste betroffene Grenze, statt automatisch den Ingress verantwortlich zu machen.
LibreTranslate auf Dockup bereitstellen, ohne seine Grenzen zu verlieren
Ein Dockup-Template sollte Image, Port 5000, Mounts, Health-Timing, Domain, TLS und Secret-Bereitstellung abbilden. Dockup sollte die Laufzeiteinstellungen von LibreTranslate beibehalten, während der Betreiber diese lokale Anforderung bestätigt: Speicher für Modelldownloads sowie eine für die Sprachpaare geeignete CPU oder GPU. Dieselbe Bereitstellung kann auf Dockup-Server oder kundenseitig angebundene Kapazitäten ausgerichtet werden.
Sobald die Route aktiv ist, wenden Sie die öffentliche Einstellung an und versuchen Sie, installierte Sprachen aufzulisten, einen festen Satz in beide Richtungen zu übersetzen sowie API-Key-Kontingent und Fehlerantworten zu prüfen. Sichern Sie heruntergeladene Modelle, die API-Key-Datenbank und die benutzerdefinierte Konfiguration und nehmen Sie die Wiederherstellungsübung in den Betriebsplan auf. Diese Aufgaben liegen in der Verantwortung von LibreTranslate und bleiben auch nach der Bereitstellung der Infrastruktur sichtbar.
Häufig gestellte Fragen
Was benötigt LibreTranslate für eine Produktionsbereitstellung?
Leiten Sie den LibreTranslate-Container auf Port 5000 über einen HTTPS-Origin weiter. Die lokale Laufzeitanforderung umfasst Speicher für Modelldownloads sowie eine für die Sprachpaare geeignete CPU oder GPU. Erklären Sie LibreTranslate erst dann für bereit, wenn Sie installierte Sprachen auflisten, einen festen Satz in beide Richtungen übersetzen sowie API-Key-Kontingent und Fehlerantworten prüfen können.
Welche LibreTranslate-Daten gehören in ein Backup?
Machen Sie /home/libretranslate/.local persistent und nehmen Sie heruntergeladene Modelle, die API-Key-Datenbank und die benutzerdefinierte Konfiguration in dasselbe Wiederherstellungsmanifest auf. Eine saubere LibreTranslate-Wiederherstellung ist erst dann erfolgreich, wenn Modelle und API-Key-Zustand zurückkehren und der Regressionstest mit akzeptablen Ergebnissen abgeschlossen wird.
Benötigt LibreTranslate hinter einem Reverse Proxy HTTPS?
Verwenden Sie HTTPS für den öffentlichen LibreTranslate-Origin und halten Sie Port 5000 auf der internen Route. Wenden Sie die LibreTranslate-Einstellung korrekt an: Stellen Sie die API über HTTPS bereit und dokumentieren Sie den korrekten Basispfad. Bei LibreTranslate schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, vom Origin abhängiges Client-Verhalten.
Wie sollte ein LibreTranslate-Upgrade getestet werden?
Stellen Sie den aktuellen LibreTranslate-Zustand in einer isolierten Bereitstellung wieder her, wenden Sie die Kandidatenversion an und wiederholen Sie die Abnahmetransaktion. Gehen Sie dabei besonders sorgfältig vor, da Modellpakete und Server-Releases das Übersetzungsergebnis verändern können. Pflegen Sie daher einen kleinen Regressionstest. Behalten Sie das vorherige LibreTranslate-Image, bis die Grenzen für Datenmigration und Rollback verstanden sind.