Avant de commencer

Quatre choses. Trois d’entre elles, toi seul peux les fournir.

La machine

Ubuntu 26.04 LTS est ce pour quoi l’installateur est réglé ; tout ce qui va de 22.04 fonctionne. 2 vCPU, 4 Go de RAM, au moins 20 Go de disque.

3,7 Go de RAM suffisent — l’installateur provisionne un fichier d’échange de 4 Go. En dessous, les constructions de surfaces échouent : une construction interrompue par le signal 137 signifie que la machine manque de mémoire. Le nœud s’installe et tourne quand même si une construction de surface échoue ; seul ce portail est sauté, et relancer l’installation la retente.

Le profil à 4 Go fait tourner la base de données, l’authentification, le REST, les fonctions edge, la passerelle, le stockage et le temps réel. Studio, les analyses, le proxy d’images et le pool de connexions sont désactivés par défaut.

Tu n’as pas besoin d’installer Docker, Node.js ou pnpm toi-même. Le préambule de l’installation le fait, et configure le pare-feu pour autoriser les ports 22, 80 et 443.

Le domaine

Un domaine que tu contrôles pour le nœud — node1.example.com, disons — et la capacité de définir un enregistrement A pointant vers l’IP publique de la machine.

Chaque surface web que tu actives a besoin de son propre enregistrement A aussi (admin.node1.example.com, my.node1.example.com, et ainsi de suite). L’installateur imprime chaque enregistrement dont il a besoin.

Le fournisseur e-mail

Requis pour la mise en service. Un fournisseur SMTP porte tout le courrier du nœud : liens de connexion, confirmation d’inscription et réinitialisation de mot de passe depuis le service d’authentification, et invitations, notifications et codes de vérification depuis les fonctions edge.

L’installateur demande l’hôte, le port, l’utilisateur et le mot de passe, vérifie la configuration contre le fournisseur réel avant d’installer quoi que ce soit, et propose de t’envoyer un message de test.

Fournisseur	Hôte	Port	Utilisateur	Mot de passe
Resend	smtp.resend.com	465	resend	ta clé API
Postmark	smtp.postmarkapp.com	465	jeton serveur	jeton serveur
Le tien	selon le fournisseur	465	selon le fournisseur	selon le fournisseur

Utilise le port 465, qui est du TLS implicite. Ce n’est pas une préférence. Sur le port 587, le moteur d’exécution des fonctions du nœud ne termine pas la montée en puissance STARTTLS. L’envoi reste en attente, expire et échoue, si bien que les invitations, notifications et codes de vérification ne partent pas.

Deux vérifications passent quand même, ce qui rend ça difficile à repérer. Le contrôle d’installation utilise un client de messagerie différent et se connecte sur le port 587 sans problème. Les liens de connexion et les réinitialisations de mot de passe continuent d’arriver, parce que le service de connexion est un programme séparé avec son propre client de messagerie — donc t’envoyer un lien de connexion, le test que la liste de vérification demande, réussit sur un nœud dont l’e-mail applicatif est cassé.

Le port 25 sortant est bloqué chez la plupart des hébergeurs.

L’adresse d’expédition doit être un domaine vérifié. Le nœud envoie par défaut en tant que noreply@<home_server>, et les fournisseurs rejettent tout envoi depuis un domaine qu’ils n’ont pas vérifié pour SPF et DKIM. Ce n’est pas ton admin_email — c’est ton adresse de connexion et de contact personnelle, et son domaine n’est pas vérifié. Si ton nœud est un sous-domaine sur un compte où seul le domaine parent est vérifié, règle smtp.sender_email sur le parent vérifié. L’e-mail de test à l’installation attrape ça avant que tu ailles en production.

Sans e-mail, le nœud est presque inerte. Les utilisateurs rejoignent par des liens d’invitation liés à un e-mail, donc un nœud qui ne peut pas envoyer de courrier ne peut accueillir personne. L’installateur force aussi chaque surface de fédération à l’arrêt quand aucun transport n’est configuré, et te le dit. Le seul nœud qui tourne légitimement sans e-mail est celui réglé sur registration_mode: closed, qui n’accepte aucun nouvel utilisateur. Les inscriptions ne sont jamais confirmées automatiquement sur un nœud.

Le logiciel

tc-operator tourne depuis une arborescence source complète. Tu reçois l’archive de distribution de l’exploitant de la part de Trusted Codes — une archive tar contenant l’arborescence complète compilable, sans historique de contrôle de version et sans document interne.

Si on t’a donné un jeton d’inscription, tu ne récupères pas l’archive à la main du tout ; l’installateur en une ligne le fait pour toi et vérifie le téléchargement contre le manifeste de version publié et signé. Voir Installer un nœud.

Ce que tu ne configures pas

La racine de confiance de la fédération — l’URL du registre central et sa clé publique racine — est intégrée dans l’installateur. C’est une seule valeur pour tout le maillage, identique sur chaque nœud, et tu ne la fournis ni ne la changes.

Chaque secret propre au nœud (le secret JWT, les clés anonymes et de service, le mot de passe Postgres, la clé de chiffrement, la clé de signature de fédération) est généré pour toi dans /etc/trusted-codes/secrets.env, mode 0600. Tu ne copies jamais un secret à la main. La seule exception est ton mot de passe SMTP, que tu places dans operator.yaml.

Une répétition, si tu en veux une

Sur un poste de travail Mac ou Linux avec Docker, tu peux faire tourner tout le flux de conteneurs sans aucun provisionnement d’hôte ni TLS :

scripts/tc-operator/tc-operator install --local --config operator.yaml

--local démarre le nœud sur un projet de bouclage isolé et saute entièrement apt, le pare-feu, le fichier d’échange et le TLS. Démonte-le avec tc-operator uninstall --local --config operator.yaml --purge.