Salta ai contenuti
Guida di Trusted Codes

tc-operator

tc-operator è il comando che installa e gestisce un nodo Trusted Codes sulla tua macchina. Un comando solo su un server nuovo trasforma la macchina in un home server completo, capace di federazione.

Questa è una capacità Enterprise, ed è l’unica cosa per cui esiste tc-operator. Gestire un proprio nodo federato fa parte del piano Enterprise; lo strumento esiste per installare, configurare e mantenere un nodo simile e non fa nient’altro. Se sei su qualsiasi altro piano, niente in questa pagina ti riguarda — l’app per telefono, il client desktop e i portali parlano tutti con server che gestiamo noi, e non c’è nulla per te da gestire. Nessuno ha bisogno di tc-operator per usare Trusted Codes.

Questa sezione è il percorso che percorri: decidere se ne vuoi uno, installarlo, configurarlo, gestirlo giorno per giorno, e smantellarlo di nuovo. Che cosa sia un server federato — la mesh, l’ammissione, che cosa passa tra server — è coperto nella sezione Server federato.

Che cosa ottieni

Sezione intitolata “Che cosa ottieni”

L’intero backend sulla tua macchina: il database, il servizio di accesso, lo strato REST, le edge function che custodiscono tutta la logica di business, il gateway API, l’archiviazione file e il realtime. Gira lo stesso schema e lo stesso codice dei server che gestisce Trusted Codes, dietro HTTPS sul tuo dominio.

Il nodo è solo backend. I client sono l’app per telefono, il companion desktop e MCP — non c’è nessun client web da distribuire. Il nodo serve un insieme di superfici web (l’app di amministrazione, e facoltativamente il portale utente, il portale business, le pagine verify e status) sotto il tuo dominio, e scegli tu quali.

Gli account dei tuoi membri, le connessioni, le parole di codice e i vault vivono nel tuo database e da nessun’altra parte.

Che cosa ti costa

Sezione intitolata “Che cosa ti costa”

Una macchina che tieni accesa. La macchina di riferimento è Ubuntu 26.04 (va bene qualsiasi cosa da 22.04 in su), 2 vCPU, 4 GB RAM, 20 GB di disco. L’installer provisiona uno swapfile da 4 GB. Le build delle superfici sono affamate di memoria; sotto i 4 GB vengono terminate.

Un dominio e il suo DNS. Il nodo ha bisogno di un record A, e ogni superficie che attivi ne ha bisogno di uno proprio.

Un provider email. Un solo provider SMTP porta tutta la posta del nodo. Un nodo senza uno non può accogliere nessuno, e si avvia con ogni superficie di federazione forzata a spenta.

Backup che fai tu stesso. L’installer fa un dump del database solo quando disinstalli. Un nodo attivo ha bisogno di una tua schedulazione — e il solo dump non basta per il ripristino. Vedi Backup e ripristino.

Restare aggiornato. Un nodo non è un fork privato. Gli aggiornamenti arrivano come nuovi archivi di distribuzione e li applichi tu.

Che cosa non è tuo da gestire

Sezione intitolata “Che cosa non è tuo da gestire”

La fatturazione e le credenziali push per il telefono restano centrali. Così anche il tetto dei diritti sotto cui gira il tuo nodo: è concesso e firmato centralmente, e il ruolo di amministratore del tuo nodo non può alzarlo. La sezione sulla federazione spiega perché.

Le parti a senso unico

Sezione intitolata “Le parti a senso unico”

Leggile prima di iniziare, non dopo.

  • uninstall --purge distrugge il nodo e i suoi dati. Fa prima un dump e rifiuta senza --purge quando esistono utenti reali, ma oltre quella conferma non c’è ritorno.
  • rollback riporta indietro solo il codice. Lo schema del database è solo in avanti e non viene riportato indietro. Il codice vecchio gira allora contro lo schema attuale.
  • Perdere /etc/trusted-codes/secrets.env perde il nodo. I dati ripristinati sono illeggibili senza la chiave di cifratura originale, e il nodo ottiene una nuova identità di federazione. Fanne un backup insieme a ogni dump.
  • home_server non può essere cambiato su un nodo in esecuzione. Cambiarlo è una nuova identità: nuovo DNS, nuovo TLS, nuova ammissione.

Dove andare adesso

Sezione intitolata “Dove andare adesso”