operator.yaml

operator.yaml est le seul fichier que tu édites. Copie-le depuis scripts/tc-operator/operator.yaml.example, garde-le en mode 0600, et ne le commite jamais — il contient ton mot de passe SMTP, qui est le seul secret qu’il porte. Tout autre secret est généré dans /etc/trusted-codes/secrets.env.

Requis

home_server: node1.example.com
admin_email: ops@example.com

home_server est l’identité du nœud. Il ne peut pas être changé sur un nœud en marche — voir Limites ci-dessous.

E-mail

smtp:
  host: smtp.resend.com
  port: 465
  user: resend
  pass: <ta clé API>
  sender_name: Ton nœud
  sender_email: '' # par défaut noreply@<home_server>

Un fournisseur pour tout le courrier du nœud. Garde le port à 465. Voir Avant de commencer pour savoir pourquoi, et pour l’exigence de domaine vérifié, qui est l’autre chose qui tourne mal d’habitude.

Qui peut détenir un compte

auth:
  registration_mode: invitation_only

Seuls invitation_only (par défaut) et closed sont à toi de régler. Tu peux restreindre, jamais assouplir. L’inscription ouverte et organique est autorisée de façon centrale par la licence signée du nœud ; mettre open ici est ignoré et traité comme invitation_only.

Deux questions liées ne sont pas réglées dans ce fichier, et sont réglées dans l’application d’administration sous les réglages du nœud à la place :

Ce qui se passe quand l’un de tes membres invite quelqu’un qui n’a de compte nulle part — refuser, ou l’envoyer s’inscrire chez Trusted Codes. Choisir de l’envoyer transmet l’adresse e-mail de la personne invitée à Trusted Codes. C’est une double porte : le serveur central doit aussi accepter les propositions venant de ton nœud, sinon l’invitation de ton membre échoue simplement, sans raison montrée.
Si d’autres serveurs peuvent placer des invitations sur ton nœud pour tes membres. C’est ton interrupteur entrant, et il peut être réglé sur refus depuis n’importe quel état.

Elles sont délibérément en dehors de ce fichier, parce que chaque reload réécrit les drapeaux de fédération sans condition — une valeur réglée ici annulerait silencieusement une décision prise plus tard.

Drapeaux de fédération

federation: true

federation: true active tout l’ensemble participant — code_lookup, open_link_claim, invitations, groups et multi_account. Toute clé spécifique à un drapeau remplace le raccourci.

Deux choses à savoir :

Un transport e-mail est un prérequis strict. Sans smtp.host, l’installateur force tout l’ensemble à l’arrêt et te le dit.
Le fichier d’exemple règle chaque drapeau explicitement sur false. Si tu le copies sans le modifier, tu obtiens un nœud avec la fédération désactivée, même si un nœud avec SMTP configuré est par ailleurs actif par défaut. Règle-les délibérément.

Ce qu’expose chaque surface, et pourquoi deux d’entre elles ont été des découvertes de sécurité, est couvert dans la section Serveur fédéré. Lis-la avant de les activer.

La découverte WebFinger est toujours active. Un nœud doit être découvrable pour fédérer.

Surfaces

Quelles surfaces web ce nœud sert sous ton domaine. Utilise la forme en bloc ; la forme en ligne my: { enabled: true } n’est pas analysée.

surfaces:
  admin:
    enabled: true
  my:
    enabled: false
  verify:
    enabled: false
  provider:
    enabled: false
  status:
    enabled: false
  business:
    enabled: false
    # host: verify.example.com   # dérogation de domaine par surface

admin est active par défaut et ne peut jamais être arrêtée — c’est la surface de récupération. Chaque surface activée est construite sur la machine et a besoin de son propre enregistrement A DNS.

Image de marque

branding:
  product_name: Trusted Codes
  primary_color: '#1a3a5c'
  # logo_url: https://node1.example.com/logo.svg

Le nom, la couleur et le logo sont publiés dans les informations signées du nœud et appliqués au contenu propre au nœud — e-mails, aide, intégration.

Intégrations optionnelles

Tout ici est optionnel. Laisse une clé vide et cette fonctionnalité est simplement désactivée : le nœud tourne quand même, et le résumé d’installation comme tc-operator status montrent quelles intégrations sont actives et lesquelles sont désactivées. Rien n’échoue silencieusement. Tu obtiens ces clés toi-même, pour ton propre déploiement ; Trusted Codes ne les voit jamais.

Intégration	Clés	Vide signifie
MaxMind — géographie et détection de fraude sur les connexions et recherches	`integrations.maxmind.account_id`, `license_key`	les connexions se poursuivent sans notation : en cas de panne, tout passe
Assistant IA	`integrations.ai.mistral_api_key` ou `gemini_api_key`	l’assistant est désactivé
Metabase — tableaux de bord embarqués dans l’application d’administration	`integrations.metabase.site_url`, `embedding_secret`	tableaux de bord indisponibles

Le défaut pour MaxMind mérite un second regard. Pour un nœud qui devrait bloquer les connexions quand la notation est indisponible plutôt que les laisser passer, il y a un paramètre séparé à régler.

La facturation et les notifications push mobile sont centrales uniquement et n’ont aucun réglage ici.

Relais push

push_relay_server: app.trusted.codes

Un nom de serveur de fédération, pas une URL. Ton nœud possède les jetons push de ses utilisateurs, mais l’identifiant push de l’application mobile partagée appartient à Trusted Codes, donc ton nœud ne peut pas parler directement aux services push des stores d’applications. Une fois réglé, les notifications push voyagent comme des enveloppes de fédération signées à travers le relais.

Le relais voit un jeton, une heure et le nom de ton serveur. Jamais de contenu. Dans cette version, seuls des signaux silencieux de « réveille-toi et synchronise » voyagent ; l’appareil récupère ensuite et affiche les vraies données depuis ton nœud. La conséquence est réelle : tes utilisateurs obtiennent des réveils de synchronisation en arrière-plan, pas de texte de notification poussé par le serveur. Les alertes visibles apparaissent quand l’application revient au premier plan et se synchronise.

Le laisser non réglé garde les envois directs, qui fonctionnent jusqu’à ce que la sécurité push soit activée sur toute la plateforme. Si le push tombe entièrement, rien ne casse — les clients convergent sur les balayages au premier plan. Le push n’est jamais un pilier de ce produit.

Appliquer un changement à un nœud en marche

sudo scripts/tc-operator/tc-operator reload --config operator.yaml

Pense à ça comme amener tout le nœud à ce que le fichier dit maintenant. Ça revérifie le SMTP contre le fournisseur réel avant d’appliquer quoi que ce soit, rend à nouveau secrets.env depuis le fichier, laisse Docker recréer exactement les conteneurs dont les réglages ont changé, réapplique les réglages côté base de données (drapeaux de fédération, bascules de surfaces, image de marque, URL de portails), signe à nouveau les informations publiées du nœud, recharge le proxy à chaud et s’auto-teste.

Les secrets générés — les clés JWT, les clés de chiffrement, l’identité de fédération — ne sont jamais renouvelés par un reload. Une configuration inchangée ne fait rien, donc c’est sûr de le lancer à tout moment.

Couvert : smtp, auth, integrations, branding, surfaces, les drapeaux de fédération, push_relay_server, et les dérogations de registre et de licence.

Ce que reload ne fera pas

home_server ne peut pas être rechargé. Le changer est un changement d’identité — DNS, TLS, admission au registre. Reload refuse et te renvoie vers l’installation.
admin_email n’est que partiellement appliqué. Reload met à jour l’adresse de contact du certificat. Un nouveau compte admin a besoin de tc-operator add-admin --email <addr>.
Une surface nouvellement activée n’est pas construite. Reload avertit et te renvoie vers tc-operator service start <surface>, qui la construit et la sert.
Reload fait autorité pour les surfaces. Toute bascule ponctuelle faite dans l’application d’administration depuis la dernière réconciliation est remise à ce que déclare le fichier. L’installation se comporte de la même façon.
Le nouveau code et les nouvelles migrations ne voyagent jamais par reload. C’est le rôle de la mise à jour.