Zum Inhalt springen
Self-HostingServer auf Anfrage erhältlich

Betreiben Sie den Server dort, wo Sie schon arbeiten

Der Crunu-Server ist von Grund auf blind. Ob auf app.crunu.com oder auf Infrastruktur unter Ihrer Kontrolle: Er speichert Chiffretext, öffentliche Schlüssel und signierte Datensätze und hat keinen Schlüssel, der auch nur einen einzigen Wert entschlüsselt.

Beispiel. Kiteline ist ein fiktives Unternehmen.

Was Sie zuerst brauchen

  • 1Node.js 24 und der ServercodeDarauf laufen die Werkzeuge für Betreiber server-init, doctor und crunu-server. Der Server ist kein öffentlicher Download: Schreiben Sie an support@crunu.com, um ihn zu erhalten.
  • 2Eine Adresse, die Sie behaltenAnmeldesignaturen, Freigabelinks, Passkeys und Agenten sind an die Domain des Servers gebunden, sie lässt sich später also nicht ändern.
  • 3Ein sicherer Ort für .envEin Passwortmanager eignet sich. Die Datei enthält SERVER_KEY, das wichtigste Geheimnis des Servers.

Einmal pro Server

Installieren

Fünf Schritte führen Sie von einer leeren Maschine oder einem leeren Cloud-Konto zu einem laufenden Server mit seinem ersten Owner.

  1. 1Entscheiden Sie, wer den Server betreibt

    Verschlüsselt wird im Browser und im Agenten crunu, nie auf dem Server. Bei der Wahl zwischen app.crunu.com und Ihrem eigenen Server geht es also darum, wer ihn betreibt und wer seine Metadaten sieht. In beiden Fällen kann niemand auf der Serverseite Ihre Werte lesen.

    • app.crunu.com: Crunu betreibt den Server auf Cloudflare Workers mit einer D1-Datenbank, kostenlos im Early Access
    • Ihr eigener Server: Sie betreiben ihn, Sie bezahlen Ihren Plattformanbieter, und nur Sie sehen seine Metadaten
    • Metadaten sind die Namen von Organisationen, Projekten, Umgebungen und Maschinen, E-Mail-Adressen, das Audit-Log sowie Größe und Zeitpunkt von Versionen
    Beispiel. Kiteline ist ein fiktives Unternehmen.
  2. 2Erzeugen Sie die Einstellungen des Servers

    server-init schreibt eine Datei .env mit einem neuen SERVER_KEY, einem einmaligen BOOTSTRAP_TOKEN für den ersten Owner und einem CRON_SECRET. Nur Ihr Benutzer kann die Datei lesen.

    • Speichern Sie sofort eine Kopie in Ihrem Passwortmanager
    • Geht SERVER_KEY verloren, werden alle abgemeldet, und Freigabelinks funktionieren nicht mehr. Die Daten der Umgebungen bleiben erhalten
  3. 3Wählen Sie eine von fünf Plattformen

    Jede Plattform betreibt denselben Server mit demselben Datenbankschema, und die Web-App ist darin enthalten. Jedes Deploy-Skript prüft .env mit dem Code, den der Server beim Start verwendet, also bricht eine falsche Einstellung das Deployment mit einer klaren Meldung ab.

    • Docker auf Ihrem eigenen Server: Caddy stellt TLS-Zertifikate aus, und Cloudflare Tunnel funktioniert, wenn Sie keine offenen Ports wollen
    • Cloudflare Workers: Free genügt für einen Test, ein Team braucht aber Workers Paid, denn Free gibt jeder Anfrage 10 ms CPU-Zeit
    • Vercel: Previews bekommen eine eigene Datenbank und einen eigenen Serverschlüssel, und im Tarif Hobby läuft die Bereinigung höchstens einmal am Tag
    • AWS App Runner nur in AWS-Konten, die es bereits nutzen: AWS hat es für Neukunden geschlossen, und Crunu hat kein Skript für Amazon ECS Express Mode
    Beispiel. Kiteline ist ein fiktives Unternehmen.
  4. 4Deployen Sie mit dem Skript der Plattform

    Ein Befehl pro Plattform baut und deployt den Server. Secrets erreichen die Plattform über stdin oder eine Datei, die nur Sie lesen können, nie über Befehlsargumente oder Ausgaben. Datenbankmigrationen führt der Server beim Start selbst aus.

    • Dasselbe Skript installiert die erste Version und jedes Update
    • Auf Cloudflare gehen Code und Secrets als eine Version hinaus, ein fehlgeschlagenes Deployment ändert also nichts
  5. 5Legen Sie den ersten Owner an

    Öffnen Sie die Adresse des Servers und geben Sie den Bootstrap-Schlüssel aus .env ein. Die Schlüssel Ihres Kontos und Ihrer Organisation werden in Ihrem Browser erzeugt, und der Bootstrap-Schlüssel funktioniert nach diesem einen Einsatz nicht mehr. Sichern Sie danach Ihr Emergency Kit, erstellen Sie einen Wiederherstellungscode und schalten Sie einen zweiten Faktor ein.

    • Ohne Emergency Kit und Passwort kann sich ein neues Gerät nicht anmelden
    • Alle anderen kommen per Einladung dazu

Jeden Tag

Betreiben

Läuft der Server, halten ihn drei Gewohnheiten gesund: eine Prüfung nach jedem Deployment, Überwachung und ein tägliches Backup.

  1. 6Prüfen Sie das Deployment mit doctor

    doctor prüft einen laufenden Server von außen: Zustand, TLS und Ablauf des Zertifikats, Sicherheits-Header, Komprimierung der API-Antworten, Serveruhr, Agent-Release, Migrationen, Bereinigung und die Clientadresse hinter Proxys.

    • Ein Gesamtergebnis und ein Exit-Code, passend für cron und CI
    • --json liefert maschinenlesbare Ausgabe
  2. 7Überwachen Sie Zustand, Metriken und Warnungen

    GET /v2/health funktioniert mit Uptime-Diensten wie UptimeRobot oder Better Stack. GET /v2/status liefert mit einem Betreiber-Token Metriken als JSON oder im Prometheus-Format, ohne Werte und ohne E-Mail-Adressen. Warnungen erreichen Ihr Team über einen signierten Webhook oder per E-Mail.

    • Slack, Microsoft Teams und PagerDuty werden über ihre eingehenden Webhooks angebunden
    • Auf Cloud Run und App Runner läuft die Bereinigung nur bei Traffic, zustandsbasierte Warnungen können also verspätet ankommen
  3. 8Sichern Sie in einen Speicher Ihrer Wahl

    crunu-server export schreibt die ganze Datenbank in ein Archiv. Es enthält keine offenen Werte, Sie können es also bei jedem Anbieter aufbewahren. Bewahren Sie die Datei .env getrennt davon in Ihrem Passwortmanager auf.

    • Exportieren Sie täglich und bewahren Sie 30 Tage auf. Der Server hat keinen eingebauten Scheduler, und die Anleitung zu Backups enthält eine fertige cron-Zeile für Docker
    • Prüfen Sie jeden Monat eine Kopie, besser noch: Stellen Sie sie in einer Testdatenbank wieder her
    • Eine Wiederherstellung setzt alles nach der Kopie zurück, und Geräte, die neuere Daten gesehen haben, verweigern den älteren Stand, bis Sie sie zurücksetzen

Bei Bedarf

Ändern

Für Umzug, Rotation des Serverschlüssels und Updates nutzen Sie die Deploy-Skripte und crunu-server, die Sie schon haben.

  1. 9Ziehen Sie mit einem Archiv auf eine andere Plattform um

    Exportieren Sie die Datenbank, prüfen Sie das Archiv, importieren Sie es in eine leere Datenbank auf der neuen Plattform, deployen Sie dort mit derselben .env und stellen Sie dann das DNS um. Jede der sechs Konfigurationen kann zu jeder anderen umziehen, in beide Richtungen.

    • Behalten Sie denselben SERVER_KEY und dieselbe Adresse. Nur der DNS-Eintrag ändert sich
    • Maschinen laufen mit den Variablen weiter, die sie für ihre Lease schon haben, bis zu 24 Stunden
    • Behalten Sie die alte Plattform eine Woche lang. Der Weg zurück ist eine DNS-Änderung
    Beispiel. Kiteline ist ein fiktives Unternehmen.
  2. 10Rotieren Sie den Serverschlüssel, ohne jemanden abzumelden

    Während einer Rotation funktioniert der bisherige Schlüssel weiter, Tokens werden bei ihrer Nutzung mit dem neuen Schlüssel neu gehasht, und rotate-key verschlüsselt TOTP-Geheimnisse und Warnkanäle neu. Personen bleiben angemeldet, und Freigabelinks öffnen sich weiter. Daten der Umgebungen werden nie mit diesem Schlüssel verschlüsselt.

    • Vier Schritte: new-server-key, deploy, rotate-key, drop-previous-key
    • Rotieren Sie, wenn .env gesehen worden sein könnte, nach einem Umzug oder einmal im Jahr
  3. 11Aktualisieren Sie ohne eigenen Migrationsschritt

    Ein Update ist dasselbe Deploy-Skript wie die Erstinstallation, und der Server führt Migrationen beim Start aus. Migrationen fügen nur hinzu, und veröffentlichte sind durch Prüfsummen geschützt, Sie können den Code also zurückrollen, ohne die Datenbank zurückzurollen.

    • Web-Releases sind signiert, und der Server liefert die Signatur aus, damit eine deployte Website damit abgeglichen werden kann
    • Ein Zurückrollen unter Version 6.0 ist nicht möglich

Fragen zum Self-Hosting

Was Betreiber fragen, bevor sie einen eigenen Server aufsetzen.

Eine andere Frage? Schreiben Sie an support@crunu.com.

Ist app.crunu.com dieselbe Software, die ich selbst hosten kann?

Ja. Auf app.crunu.com läuft derselbe Crunu-Server, deployt auf Cloudflare Workers mit einer D1-Datenbank.

Können die Betreiber von app.crunu.com meine Secrets lesen?

Nein. Der Server speichert Chiffretext und hat keinen Schlüssel, um ihn zu entschlüsseln. Als Betreiber sieht Crunu allerdings Metadaten: die Namen von Organisationen, Projekten, Umgebungen und Maschinen, E-Mail-Adressen, das Audit-Log sowie Größe und Zeitpunkt jeder Version. Ein Risiko gilt für jeden webbasierten Tresor: Ein kompromittierter Server könnte eine veränderte Web-App ausliefern, die Ihr Passwort und Ihren Secret Key bei der Anmeldung sieht. Signierte Releases und eine strenge Content Security Policy verringern dieses Risiko, und die Seite zu den Grenzen erklärt den Rest.

Kann ich später von app.crunu.com auf meinen eigenen Server umziehen?

Nicht in einem Schritt. Das Archiv, mit dem ein Server zwischen Plattformen umzieht, entsteht aus der ganzen Datenbank des Servers, und auf app.crunu.com hat nur der Betreiber darauf Zugriff. Sie können jederzeit jede Umgebung, die Sie lesen können, als .env-Datei exportieren oder eine Offline-Kopie herunterladen und diese Dateien dann Ihrem eigenen Server hinzufügen. Verlauf, Zugriffseinstellungen und Audit-Log werden auf diesem Weg nicht übernommen.

Wird AWS unterstützt?

Teilweise. Das Crunu-Skript deployt auf AWS App Runner, aber AWS hat App Runner für Neukunden geschlossen, es funktioniert also nur in Konten, die es bereits nutzen. Für Amazon ECS Express Mode, den Dienst, den AWS stattdessen empfiehlt, hat Crunu kein Skript. Wählen Sie mit einem neuen AWS-Konto Cloud Run, Vercel oder Ihren eigenen Server.

Was passiert während eines Umzugs mit Maschinen und CI?

Maschinen laufen mit den Variablen weiter, die sie schon haben, für die Dauer ihrer Lease, bis zu 24 Stunden. Bitten Sie das Team, während der Umstellung 15 bis 30 Minuten lang keine Umgebungen zu ändern und niemanden einzuladen: Was nach dem Export auf den alten Server geschrieben wird, erreicht den neuen nicht.

Kann ich mehrere Serverinstanzen für Hochverfügbarkeit betreiben?

Auf Postgres können sich mehrere Instanzen eine Datenbank teilen: Schreibvorgänge ins Audit-Log werden durch eine Datenbanksperre serialisiert. Eine Anleitung für einen Failover-Cluster gibt es nicht, planen Sie ihn also als eigene Konfiguration.

Haben die Werkzeuge für Betreiber eine englische Oberfläche?

Ja. server-init, doctor und crunu-server geben ihre Meldungen auf Englisch aus oder auf Russisch, wenn CRUNU_LANG oder die Locale des Systems Russisch ist.

Wie erhalte ich den Server für das Self-Hosting?

Der Server wird nicht als öffentlicher Download angeboten. Schreiben Sie an support@crunu.com und nennen Sie die Plattform, die Sie nutzen möchten.

Testen Sie Crunu zuerst im gehosteten Dienst

Kostenlos im Early Access. Ihr Passwort und Ihr Secret Key werden in Ihrem Browser erzeugt und erreichen nie den Server.