Selbst hosten

Sie können die Oloproof-Workbench auf Ihrem eigenen Server betreiben: vor Ort, in einer privaten Cloud oder bei einem kanadischen Cloud-Anbieter. Das Paket in deploy/self-hosted/ startet dieselben zwei Images wie oloproof.com (Web und Worker) sowie PostgreSQL, per Digest gezogen. Ihre Daten bleiben dort, wo Sie es betreiben, und nichts wird an Oloproof gesendet.

Voraussetzungen

• Ein Linux-Host mit Docker Engine und dem Compose-Plugin. 4 GB Arbeitsspeicher und 2 CPUs reichen für ein Team; der Worker ist auf 1,5 GB begrenzt, das Web auf 768 MB.
• Speicherplatz für PostgreSQL. Jeder Lauf, den Sie hochladen, wird dort gespeichert.
• Ein Reverse Proxy für HTTPS (Caddyfile.example ist ein funktionierendes Beispiel; nginx geht auch).
• Zugriff auf ghcr.io/etobicoke/oloproof oder die Images in Ihre eigene Registry kopiert.

Installation

cd deploy/self-hosted
sh generate-env.sh          # writes .env and fills every secret

Setzen Sie OLOPROOF_WEB_IMAGE, OLOPROOF_WORKER_IMAGE (beide ...@sha256:-Digests) und OLOPROOF_PUBLIC_URL in .env sowie mindestens einen Anmeldeweg: E-Mail für Passwortkonten (OLOPROOF_MAIL_FROM mit OLOPROOF_SMTP_URL oder OLOPROOF_RESEND_API_KEY) oder einen OAuth-Anbieter. Ohne einen davon startet das Web nicht. Dann starten Sie es:

docker compose --env-file .env up -d
curl -fsS http://127.0.0.1:3000/api/health

Der Dienst migrate bringt die Datenbank auf den neuesten Stand, bevor Web und Worker starten. Die Registrierung erfolgt per Einladung, ausgestellt mit OLOPROOF_OPERATOR_TOKEN (deploy/README.md, „Signup“).

Konfiguration

.env.example listet jede Variable, die Web und Worker lesen, jeweils als erforderlich, generiert oder optional markiert. Eine leere optionale Variable schaltet ihre Funktion ab. Behalten Sie die generierten Geheimnisse: Ein neues Datenbankpasswort sperrt die Datenbank aus, und ein neuer Signaturschlüssel beginnt einen neuen Unterzeichner. Ein selbst gehostetes Paket hat keine Abrechnung, daher hat jeder Workspace die monatlichen Fallmengen des kostenlosen Tarifs; erhöhen Sie OLOPROOF_FREE_TIER_PUSHED_MONTHLY und OLOPROOF_FREE_TIER_MANAGED_MONTHLY für Ihr Team.

Standardmäßig kein ausgehendes Netzwerk

Der Stack sendet keine Telemetrie und ruft keinen Oloproof-Dienst auf. Er greift nur für das aufs Netzwerk zu, was Sie einschalten: E-Mail (ein SMTP-Relay in Ihrem Netzwerk oder Resend), OAuth-Anmeldung, Turnstile und die Modellanbieter, für die ein Workspace einen Schlüssel speichert. Ist nichts davon gesetzt, läuft er ohne Route nach außen. Für einen abgeschotteten Host kopieren Sie die drei Images in Ihre eigene Registry und richten die Image-Variablen darauf aus. Passwortkonten brauchen E-Mail; setzen Sie daher in einem abgeschotteten Netzwerk OLOPROOF_SMTP_URL auf ein Relay darin.

Sicherungen

sh backup.sh /srv/backups/oloproof

backup.sh schreibt einen komprimierten pg_dump in das Verzeichnis Ihrer Wahl. Planen Sie es mit cron oder einem systemd-Timer, und kopieren Sie das Verzeichnis selbst vom Host weg. Das Skript zeigt den Wiederherstellungsbefehl an.

Der Dump enthält .env nicht, und .env enthält OLOPROOF_CONTENT_KEY und die übrigen erzeugten Geheimnisse: Ohne die Datei kann eine wiederhergestellte Datenbank ihre verschlüsselten Inhalte nicht lesen. Sichern Sie .env beim Anlegen und nach jeder Änderung, getrennt von den Dumps und offline (Passwortmanager oder verschlüsseltes Laufwerk), nie daneben.

Aktualisierungen

Tragen Sie die zwei Digests des neuen Release in .env ein und führen Sie dann aus:

sh upgrade.sh /srv/backups/oloproof

Es sichert, zieht, migriert und startet Web und Worker neu. Rechnen Sie mit einer kurzen Unterbrechung. Zum Zurückrollen tragen Sie die vorherigen Digests ein und stellen die erstellte Sicherung wieder her.

Was unterstützt wird

• Ein Host. Es gibt keine Hochverfügbarkeit: Der Stack ist so verfügbar wie seine Maschine.
• Die Datenresidenz ist dort, wo Sie ihn betreiben. Oloproof hält keine Ihrer Daten.
• Keine Releases ohne Ausfallzeit. Diese gibt es nur beim gehosteten Dienst.
• Das Paket wird von deploy/self-hosted/check.sh geprüft, das es unter einem eigenen Projektnamen startet, auf /api/health wartet, die öffentlichen Seiten abruft und es wieder entfernt.