Zum Inhalt springen

tc-operator

tc-operator ist der Befehl, der einen Trusted-Codes-Knoten auf deiner eigenen Maschine installiert und betreibt. Ein Befehl auf einem frischen Server macht die Box zu einem vollständigen, föderationsfähigen Heimatserver.

Das ist eine Enterprise-Funktion, und das ist das Einzige, wofür tc-operator da ist. Einen eigenen föderierten Knoten zu betreiben gehört zum Enterprise-Plan; das Werkzeug existiert, um einen solchen Knoten zu installieren, zu konfigurieren und zu warten, und tut sonst nichts. Bist du auf einem anderen Plan, betrifft dich nichts auf dieser Seite — die Mobile App, der Desktop-Client und die Portale sprechen alle mit Servern, die wir betreiben, und es gibt nichts für dich zu betreiben. Niemand braucht tc-operator, um Trusted Codes zu nutzen.

Dieser Abschnitt ist der Weg, den du gehst: entscheiden, ob du einen willst, ihn installieren, konfigurieren, im Alltag betreiben und ihn wieder abbauen. Was ein föderierter Server ist — das Mesh, die Aufnahme, was zwischen Servern übertragen wird — steht im Abschnitt Föderierter Server.

Das vollständige Backend auf deiner Box: die Datenbank, den Anmeldedienst, die REST-Schicht, die Edge Functions, die die gesamte Geschäftslogik tragen, das API-Gateway, den Dateispeicher und Realtime. Es läuft mit demselben Schema und demselben Code wie die Server, die Trusted Codes betreibt, hinter HTTPS auf deiner eigenen Domain.

Der Knoten ist reines Backend. Die Clients sind die Mobile App, der Desktop-Begleiter und MCP — es gibt keinen Web-Client zum Ausrollen. Der Knoten stellt aber eine Reihe von Web-Oberflächen bereit (die Admin-App und optional das Nutzerportal, das Business-Portal, Verify- und Status-Seiten) unter deiner Domain, und du wählst, welche.

Die Konten, Verbindungen, Codewörter und Tresore deiner Mitglieder liegen in deiner Datenbank und nirgendwo sonst.

Eine Maschine, die du am Laufen hältst. Die Referenzbox ist Ubuntu 26.04 (alles ab 22.04 funktioniert), 2 vCPU, 4 GB RAM, 20 GB Speicher. Der Installer legt eine 4-GB-Swapdatei an. Oberflächen-Builds sind speicherhungrig; unter 4 GB werden sie abgebrochen.

Eine Domain und ihr DNS. Der Knoten braucht einen A-Record, und jede Oberfläche, die du aktivierst, braucht einen eigenen.

Einen E-Mail-Provider. Ein SMTP-Provider trägt die gesamte Post des Knotens. Ein Knoten ohne einen kann niemanden an Bord holen und startet mit jeder Föderations-Schnittstelle erzwungen abgeschaltet.

Backups, die du selbst machst. Der Installer erstellt nur beim Deinstallieren einen Datenbank-Dump. Ein laufender Knoten braucht deinen eigenen Zeitplan — und der Dump allein reicht nicht zur Wiederherstellung. Siehe Backups und Wiederherstellung.

Aktuell bleiben. Ein Knoten ist kein privater Fork. Updates kommen als neue Distributionsarchive, und du spielst sie ein.

Abrechnung und Push-Zugangsdaten für Mobilgeräte bleiben zentral. Ebenso die Berechtigungsobergrenze, unter der dein Knoten läuft: Sie wird zentral gewährt und signiert, und die Admin-Rolle deines Knotens kann sie nicht anheben. Der Föderationsabschnitt erklärt, warum.

Lies das, bevor du anfängst, nicht danach.

  • uninstall --purge zerstört den Knoten und seine Daten. Es nimmt zuerst einen Dump und verweigert die Ausführung ohne --purge, wenn echte Nutzer existieren, aber nach dieser Bestätigung gibt es kein Zurück mehr.
  • rollback setzt nur Code zurück. Das Datenbankschema ist nur vorwärts gerichtet und wird nicht zurückgesetzt. Alter Code läuft dann gegen das aktuelle Schema.
  • Den Verlust von /etc/trusted-codes/secrets.env verliert den Knoten. Wiederhergestellte Daten sind ohne den ursprünglichen Verschlüsselungsschlüssel unlesbar, und der Knoten bekommt eine neue Föderationsidentität. Sichere sie bei jedem Dump.
  • home_server kann auf einem laufenden Knoten nicht geändert werden. Ihn zu ändern ist eine neue Identität: neues DNS, neues TLS, neue Aufnahme.