Doku · Selbst gehostet
Ein Skript, signierte Images, keine Überraschungen
Eine Produktionsinstanz baut nie aus dem Quellcode. Sie bezieht pro Release drei vorgebaute Images, jedes von der Release-Pipeline signiert, orchestriert von einem Operator-Skript, das die Signaturen selbst prüft.
Das Deployment-Modell
- Eine Instanz ist ein Kunde. Isolation ist eine Deployment-Grenze; einen Multi-Tenant-Modus gibt es nicht.
- Pull-only: das App- und Worker-Image, das Edge-Image mit der gebauten Oberfläche und der nur empfangende Inbound-Mail-Dienst, jedes mit cosign signiert.
- Secrets werden pro Instanz generiert und vom Compose-File verlangt; nichts wird eingecheckt.
- Alles orchestriert ein Operator-Skript: install, configure, upgrade, status und ein Dry-Run-Modus. Jeder Lauf endet mit einer Checkliste dessen, was es nicht für Sie tun kann: DNS-Einträge, Backup-Einstellungen, Prüfschritte.
Bevor Sie starten
- Eine frische Ubuntu-22.04- oder 24.04-Instanz.
- Eine Domain unter Ihrer Kontrolle; TLS kommt automatisch über Let's Encrypt, sobald die ausgegebenen DNS-Einträge auflösen.
- Ein Modell-API-Schlüssel, außer die Instanz soll ausschließlich lokale Modelle nutzen.
- 1
Operator-Skript laden
Das Skript installiert sein eigenes Werkzeug, einschließlich cosign für die Signaturprüfung.
curl -fsSL https://raw.githubusercontent.com/Cogeto/cogeto/main/scripts/operator/cogeto -o cogeto chmod +x cogeto - 2
Erst der Dry Run
Der Check-Modus validiert die Umgebung und zeigt, was install tun würde, ohne etwas zu ändern.
sudo ./cogeto install --check --domain <your.domain> --acme-email <you> - 3
Installieren
Das Skript zieht die Release-Images, prüft ihre Signaturen, generiert Secrets und startet die Instanz.
sudo ./cogeto install --domain <your.domain> --acme-email <you> --mistral-key <key>Der Lauf endet mit einer instanzspezifischen Checkliste: die anzulegenden DNS-Einträge, zu bestätigende Backup-Einstellungen und die Prüfschritte. TLS aktiviert sich, sobald die DNS-Einträge auflösen.
- 4
Ein Release-Image jederzeit selbst prüfen
Signiert wird schlüssellos über das öffentliche Transparenz-Log, die Prüfung braucht also keinen Schlüssel von uns. Jedes GitHub-Release trägt zudem die Software-Stückliste des Images und den exakten Prüfbefehl.
cosign verify cogeto/cogeto:<version> \ --certificate-identity-regexp '^https://github.com/Cogeto/cogeto/\.github/workflows/release\.yml@refs/tags/' \ --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
Upgrades und Rollback
Laden Sie zuerst das Skript neu: Die installierte Kopie kann sich nicht selbst aktualisieren, und nur das neue Skript ergänzt Zugangsdaten, die ein neueres Compose verlangt. Das Skript verweigert unveröffentlichte Tags, führt Migrationen erneut aus, prüft die Gesundheit der Instanz und erkennt, wenn ein Release das Embedding-Modell geändert hat, samt Angebot der Neuindizierung. Rollback setzt Images zurück; Migrationen laufen nur vorwärts, und die vollständige Datenrücksetzung ist die geprobte Backup-Wiederherstellung aus dem Runbook.
curl -fsSL https://raw.githubusercontent.com/Cogeto/cogeto/main/scripts/operator/cogeto -o cogeto
chmod +x cogeto
sudo ./cogeto upgradeWas Deployment bewusst nicht ist
Kein Terraform, keine Cloud-API-Automatisierung, kein Self-Service-Provisioning, keine automatischen Updates: ein gutes Skript, von einem Menschen ausgeführt, für eine Kohorte, in der jede Instanz zählt. Backups nutzen die Bordmittel des Hosting-Anbieters, und die Wiederherstellung wird geprobt, nicht angenommen. Das Operator-Runbook deckt Provisionierung, DNS, Onboarding, Backups mit geprobter Wiederherstellung, Upgrades und Fehlersuche ab, Checkliste für Checkliste.
Lieber betreiben lassen?
Eine gehostete Instanz auf EU-Infrastruktur beginnt mit dem Pilotgespräch, nicht mit einem Anmeldeformular.