Mozhi selbst hosten: Datensparsam übersetzen mit mehreren Engines

Warum Mozhi?

Wer regelmäßig übersetzt, landet schnell bei Google Translate, DeepL oder ähnlichen Diensten – komplett mit Werbung, Tracking-Skripten und Sprachmodell-Komfort, den man gar nicht braucht. Mozhi ist ein alternatives Frontend für Übersetzungen: Die Seite selbst ist schlank, werbefrei und verzichtet im Browser auf unnötiges JavaScript.

Das Prinzip kennt man aus der Self-Hosting-Welt: Wie SearXNG für die Suche oder GoCook für Rezepte bündelt Mozhi mehrere Übersetzungs-Engines hinter einer datensparsamen Oberfläche – auf deinem eigenen Server.

Konzept: Frontend statt Direktzugriff

Mozhi funktioniert als Aggregator: Die Übersetzungs-Engines (u. a. Google, DeepL, Reverso, DuckDuckGo) werden vom Server angesprochen, dein Browser bekommt nur die Übersetzung zurück. So bleibt die Seite ohne Werbung, ohne Tracking und ohne direkte Verbindung zu den Übersetzungs-Anbietern.

• Keine Konten, keine Datenbank: Mozhi ist bewusst schlank – es gibt nichts zu registrieren und nichts zu verwalten.
• Engine wählbar: Je nach Textqualität und Datenschutzbedürfnis kannst du zwischen den unterstützten Anbietern umschalten.
• Viele Sprachen: Die Sprachauswahl folgt den Fähigkeiten der jeweiligen Engine.

Vorbereitung: Stateless – keine Volumes nötig

Mozhi braucht weder Datenbank noch persistenten Speicher: Der Container ist zustandslos. Du benötigst lediglich einen Ordner für die Compose-Datei:

mkdir -p ~/mozhi && cd ~/mozhi

• Port: Die Anwendung lauscht im Container auf 3000 – wir binden sie nur an 127.0.0.1:50535.
• Ressourcen: Mozhi ist leichtgewichtig; die Limits (2 CPU / 4 GB RAM) sind großzügig bemessen.
• User: Die Zeile user: 1000:1000 greift nur bei gemounteten Volumes – da Mozhi keine benötigt, hat sie aktuell keine Wirkung (schadet aber auch nicht).

Docker Compose – die Datei

Deine Vorlage, aufgeräumt und kommentiert:

services:
 mozhi:
 image: codeberg.org/aryak/mozhi:latest # Registry: Codeberg-Container
 # user: 1000:1000 # nur relevant, wenn Volumes gemountet werden
 deploy:
 resources:
 limits:
 cpus: "2.0"
 memory: 4G
 restart: unless-stopped
 ports:
 - "127.0.0.1:50535:3000" # Web-UI nur lokal
 # healthcheck:
 # test: wget -nv --tries=1 --spider http://127.0.0.1:3000/api/version || exit 1
 # interval: 30s
 # timeout: 5s
 # retries: 2

• Image: Mozhi wird offiziell auf der Codeberg-Registry veröffentlicht – deshalb codeberg.org/aryak/mozhi statt Docker Hub.
• Auskommentierte build: .-Zeile: Sie stammt aus der Entwicklungs-Variante und wurde entfernt – im Produktivbetrieb ziehst du das fertige Image.
• Netzwerk: Leerer networks: {}-Block und network_mode: bridge wurden entfernt – der Standard-Bridge-Modus ist ohnehin aktiv.

Konfiguration & Healthcheck

Mozhi kommt bewusst ohne große Konfigurationsliste aus – es gibt keine dokumentierten Env-Variablen, keine Datenbank und keine Volumes. Was du konfigurieren kannst, passiert im Frontend (z. B. Standard-Engine) oder über die Projekt-Doku auf Codeberg.

Healthcheck-Falle: Dein auskommentierter Healthcheck prüfte http://127.0.0.1:50535/api/version – das ist der Host-Port. Innerhalb des Containers läuft Mozhi aber auf Port 3000, der Healthcheck muss also dorthin zeigen:

healthcheck:
 test: ["CMD", "wget", "-nv", "--tries=1", "--spider", "http://127.0.0.1:3000/api/version"]
 interval: 30s
 timeout: 5s
 retries: 2

Reverse Proxy & TLS

Da die Web-UI nur an 127.0.0.1 gebunden ist, brauchst du einen Reverse Proxy, um Mozhi sicher (HTTPS) nach außen zu reichen. Da die Seite ohne WebSockets auskommt, genügt ein schlanker Server-Block:

server {
 listen 443 ssl;
 server_name uebersetzen.meine.domain;

 # TLS-Zertifikate (z. B. Let's Encrypt) ...

 location / {
 proxy_pass http://127.0.0.1:50535;
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 60s;
 }
}

Alternativ funktioniert Caddy genauso gut:

uebersetzen.meine.domain {
 reverse_proxy 127.0.0.1:50535
}

Erster Start & erste Übersetzung

Container starten und Status prüfen:

docker compose up -d
 docker compose ps
 curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:50535/api/version

• 200 – die API antwortet, Mozhi läuft.
• Im Browser http://127.0.0.1:50535 öffnen (bzw. über den Proxy deine Domain), Ausgangs- und Zielsprache wählen, Text einfügen und übersetzen lassen.
• Bei Problemen mit einer Engine einfach im Frontend auf einen anderen Anbieter umschalten.

Updates & Betrieb

• Updates: Da der Container zustandslos ist, genügt docker compose pull && docker compose up -d.
• Backup: Es gibt nichts zu sichern – keine Datenbank, keine Nutzerdaten, keine Volumes.
• Monitoring: Den Dienst mit Uptime Kuma überwachen (Healthcheck-Endpoint /api/version).
• Watchtower: Kann Mozhi gefahrlos automatisch aktualisieren (kein Datenverlustrisiko).

Häufige Probleme (FAQ)

Fazit

Mozhi ist das perfekte Beispiel dafür, wie einfach datensparsame Alternativen sein können: ein Container, keine Volumes, keine Konfiguration – und trotzdem ein spürbar saubereres Übersetzungs-Erlebnis als der direkte Weg zu den großen Anbietern. Für alle, die ohnehin schon SearXNG oder GoCook betreiben, ist Mozhi die logische Ergänzung im „Frontend statt Fremd-Dienst“-Portfolio.