🌐Infra : sites, bases de données, buckets, domaines, serveurs

La page Infra répond à « qu'est-ce qui se trouve où, et est-ce que ça marche ? » : chaque site, base de données, bucket, domaine et serveur - sur ce serveur, sur vos autres serveurs, sur Cloudflare et sur Hostinger - avec son état, ses liens (ce domaine -> ce serveur -> ce site -> cette app -> ce dépôt) et le projet Harness auquel il appartient.

Elle est désactivée par défaut : activez-la dans Réglages -> Fonctionnalités -> Page Infra. Une entrée Infra apparaît dans la barre latérale (raccourci G puis I).

Comment ça marche

Harness lit tout : ce serveur directement, vos autres serveurs via SSH (en lecture seule), Cloudflare et Hostinger avec leurs clés d'API. Il relie ce qu'il trouve : un domaine à son site, un site à son app, à sa base de données et à son dépôt git.
Il surveille pour vous : chaque adresse est vérifiée (répond-elle, son certificat est-il valide), de même que les dates d'expiration des domaines et l'espace disque, toutes les 15 minutes (infra_refresh_min) ou quand vous cliquez sur Actualiser. Un problème apparaît en haut de la page et dans vos notifications, une seule fois par incident.
Vous créez en demandant à Claude : « mets ce dossier en ligne », « crée une base de données pour mon app »... Claude suit les recettes standard (ci-dessous) et le résultat apparaît sur la page.

La page elle-même ne modifie jamais vos sites ni vos bases de données ; la seule chose qu'elle fait d'elle-même est de connecter un serveur (voir Autres serveurs). Pour changer quelque chose, demandez à Claude : chaque ligne dispose d'une zone Demander à Claude.

La page

Vue d'ensemble : un encadré « Comment ça marche » (avec un lien vers cette page) (fermez-le avec ×, rouvrez-le avec Comment ça marche en haut à droite), le nombre de chaque type de ressource avec ce qui est en panne ou à vérifier, la liste À examiner, et Ce que Harness lit : chaque source avec ce qu'elle apporte et, quand il manque quelque chose, l'étape suivante (Ajouter la clé ..., Ajouter ces droits pour un jeton Cloudflare qui ne peut pas tout lire, Connecter pour un VPS pas encore lu).
Sites, Bases de données, Buckets, Domaines : regroupés selon leur emplacement. Domaines -> Ajouter un domaine surveille un domaine de n'importe quel registrar. Recherche, filtre par projet, affichage des lignes masquées avec le bouton en forme d'œil.
Serveurs : une carte par serveur avec son adresse, son système, la mémoire / le disque / le CPU utilisés et le nombre de sites, de bases de données et de buckets qui y tournent.
Cliquez sur n'importe quelle ligne pour voir ses détails, ses liens, son dépôt (ouvre la page Git), son tableau de bord Cloudflare / Hostinger, un projet, une note, pour la masquer, ou pour interroger Claude à son sujet.

Ce qu'il lit

Source	Ce que vous voyez	Nécessite
Ce serveur	Les sites Caddy (ou nginx) et ce qui se trouve derrière chacun (dossier, port de l'app, service systemd, conteneur Docker, dépôt git), les bases PostgreSQL / MySQL (y compris dans Docker), les fichiers SQLite, les buckets Garage, le disque, la mémoire	rien
Vos autres serveurs	la même chose, lue via SSH	`python3` sur place et un accès SSH : voir Autres serveurs
N'importe quel domaine	registrar et date d'expiration (service public RDAP), qui sert son DNS (OVH, GoDaddy, Namecheap, IONOS, Gandi, o2switch...), qui héberge son adresse (un de vos serveurs, Vercel, Netlify, GitHub Pages, Shopify, Cloudflare, Webflow, Wix, Squarespace...)	rien (DNS public) ; ajoutez les domaines qu'aucun fournisseur ne liste dans Domaines -> Ajouter un domaine
Cloudflare	domaines (zones) et leur DNS, Workers et leurs adresses, Pages, buckets R2 et leurs adresses publiques, bases D1, domaines Registrar	la clé `CLOUDFLARE_API_TOKEN` (+ `CLOUDFLARE_ACCOUNT_ID`)
Hostinger	domaines avec leur date d'expiration, VPS, zones DNS	la clé `HOSTINGER_API_TOKEN`
Vercel (bêta)	projets avec leur déploiement en production (état, date, dépôt git, framework), leurs domaines ; domaines achetés chez Vercel avec leur date d'expiration ; toutes les équipes que le jeton voit	la clé `VERCEL_TOKEN`
Netlify (bêta)	sites avec leur dernier déploiement et leur dépôt git, zones DNS Netlify	la clé `NETLIFY_AUTH_TOKEN`
Supabase (bêta)	chaque projet : sa base de données (état, région, version de Postgres ; un projet gratuit en pause affiche « en pause »), ses buckets Storage, ses Edge Functions, reliés entre eux	la clé `SUPABASE_ACCESS_TOKEN`
GitHub Pages (bêta)	les sites Pages de vos dépôts, leur adresse et l'état de leur build	les jetons GitHub déjà présents dans vos clés (page Git)

Les clés se placent dans Réglages -> Clés (la page Infra y renvoie). Harness ne fait que lire avec elles. Donnez des droits de lecture seule là où le fournisseur le permet (Cloudflare, GitHub) ; les jetons Vercel, Netlify et Supabase ne peuvent pas être limités à la lecture : laissez-les non exposés aux sessions (le réglage par défaut dans Clés) pour que seule la page Infra les utilise. Un jeton auquel il manque l'un des droits ne masque que cette partie : la page vous dit laquelle.

Les recherches DNS publiques passent par un résolveur public en HTTPS (le 1.1.1.1 de Cloudflare par défaut) : il voit les noms de domaine demandés, rien d'autre. Chaque nom est interrogé au plus toutes les 6 heures.

Créer les clés

Cloudflare : dash.cloudflare.com/profile/api-tokens -> Create token -> Custom, droits (Read) : Zone, DNS, Workers Scripts, Workers Routes, Cloudflare Pages, Workers R2 Storage, D1, Registrar ; ajoutez DNS Edit si vous voulez que Claude crée des enregistrements DNS pour les nouveaux sites.
Hostinger : hPanel -> Profil -> API -> nouveau jeton.
Vercel : vercel.com/account/settings/tokens -> Create token, portée « Full account » pour voir toutes les équipes (Vercel n'a pas de jeton en lecture seule : Harness ne fait que lire).
Netlify : User settings -> Applications -> Personal access tokens -> New access token.
Supabase : supabase.com/dashboard/account/tokens -> Generate new token.
GitHub Pages : rien de plus si la page Git affiche déjà vos dépôts.

Bêta signifie écrit d'après la référence officielle de l'API du fournisseur et testé avec ses réponses documentées, mais pas encore vu sur un vrai compte : si une ligne affiche une erreur, interrogez Claude depuis cette ligne (il voit l'erreur) et signalez-le-nous.

Mon fournisseur n'est pas listé

Domaines : rien n'est nécessaire. Ajoutez le domaine dans Domaines -> Ajouter un domaine (ou demandez à Claude « surveille le domaine example.com ») : son registrar, sa date d'expiration, son fournisseur DNS et son hébergeur sont lus à partir d'informations publiques, et il est relié à votre serveur quand il pointe vers lui. Les alertes avant expiration fonctionnent de la même façon.
Un serveur (OVH, DigitalOcean, Hetzner, Scaleway...) : Ajouter un serveur, il est lu via SSH comme n'importe quel autre.
Une plateforme (Render, Railway, Fly.io, Firebase, AWS...) : ses sites apparaissent quand même grâce à leurs domaines (la page indique qui héberge chaque adresse). Une prise en charge complète est prévue fournisseur par fournisseur.

Autres serveurs

Un VPS Hostinger apparaît tout seul dès que la clé Hostinger est dans le coffre, sous le nom VPS Hostinger. S'il accepte déjà une clé SSH de ce serveur, Harness le connecte de lui-même (l'API Hostinger indique quelle clé, donc rien n'est essayé à l'aveugle). Sinon, ouvrez-le et cliquez sur Connecter : Harness ajoute sa propre clé (harness-maxxing@<this server>) au compte root du VPS via votre clé Hostinger, puis le lit. C'est la seule modification que la page Infra fait chez un fournisseur ; vous pouvez retirer la clé dans hPanel -> VPS -> Clés SSH.
Tout autre serveur : Ajouter un serveur (en haut de la page) avec son adresse, son utilisateur SSH et son port. Si aucune des clés de ce serveur n'y est acceptée, la fenêtre vous donne une ligne à exécuter sur ce serveur, puis Réessayer.
Dans le panneau d'un serveur connecté : changez le nom affiché (le nom interne, utilisé dans les liens, ne change jamais) ou Déconnectez-le (rien ne change sur le serveur).
Depuis le terminal : maxxing infra server connect <IP or Hostinger VPS id>, server rename NAME "Label".

Harness ne fait que lire les autres serveurs (sites, ports et services, Docker, bases de données, buckets, disque, mémoire). Le serveur a besoin de python3 (toutes les distributions Linux courantes l'ont).

États

OK (vert), À vérifier (orange) : une page qui répond 404, un certificat ou un domaine bientôt expiré, un enregistrement DNS qui pointe vers un autre serveur que celui qui sert le site, un disque presque plein, une sauvegarde échouée...
En panne (rouge) : pas de réponse, une erreur serveur (5xx), un domaine expiré, une ressource créée par une recette qui est introuvable.

Les alertes vont dans le fil de notifications (et sur Telegram quand son fil de discussion est activé) : un site ou un serveur qui tombe en panne puis revient, un certificat qui expire dans les 14 jours, un domaine qui expire dans les 30 puis 7 jours (s'il n'est pas renouvelé automatiquement).

Créer des choses sur ce serveur

Demandez à Claude en mots simples ; il suit une recette fixe (skill maxxing-infra, commande maxxing infra) pour que tout soit fait de la même façon, vérifié avant d'être appliqué, et apparaisse sur la page :

« Mets ce dossier en ligne » -> https://<your Harness address>/<name>/, immédiatement, sans DNS. Ces pages s'exécutent isolées (en bac à sable) : elles ne peuvent jamais toucher Harness ni votre session (une app derrière un tel chemin ne reçoit jamais votre cookie Harness et ne peut pas en définir un ; les fichiers cachés comme .env ou .git ne sont jamais servis ; la racine de l'espace de travail, le code, le dossier d'état et .ssh ne peuvent pas être publiés). Parfait pour des pages, des démos, des rapports, des sites statiques. Une app avec une connexion, un panier ou des cookies a besoin de sa propre adresse (shop.example.com) : Claude vous le conseille, et crée l'enregistrement DNS sur Cloudflare quand la clé le permet.
« Crée une base de données pour mon app » -> PostgreSQL (installé la première fois, accessible uniquement depuis ce serveur), une base et un utilisateur par app, son adresse stockée dans Clés (DB_<NAME>_URL), sauvegardée chaque nuit (tâche « Infra: database backups », 7 copies conservées dans /var/backups/maxxing-db).
« Crée un bucket » -> stockage S3 sur ce serveur (Garage), ses clés dans Clés (S3_<NAME>_...), éventuellement public à https://<your Harness address>/<name>/. Les fichiers restent sur ce disque : pour de gros fichiers publics, Cloudflare R2 est souvent préférable, Claude vous le dit.
« Ajoute mon autre serveur 203.0.113.7 » -> Claude le connecte (maxxing infra server connect) ; s'il n'accepte pas encore de clé de ce serveur, Claude vous indique la ligne à y exécuter.

Dans les conversations

Quand Claude parle de ressources, il ajoute un petit bloc infra que l'app affiche en direct (état, lien vers la page) :

```infra
site: shop.example.com
database: shop
```

Lignes : site, database, bucket, domain, server, worker, pages, id (une ressource chacune), ou filtres project: acme, kind: database, location: <server>. Affiché quand la page Infra est activée (sinon le texte reste tel quel).

Terminal

Sécurité de `infra.json`

Les serveurs de <workspace>/infra.json sont joints par ssh par le serveur lui-même, donc Claude ne peut pas modifier ce fichier (il figure dans les règles de refus de chaque tour, comme les réglages des dossiers) ; utilisez maxxing infra server add ou la page. Une entrée écrite à la main que la CLI refuserait (utilisateur, hôte ou chemin de clé étranges) est ignorée. Un fournisseur qui ne répond pas (Cloudflare, Hostinger, un serveur) ne laisse vide que sa propre section : les vérifications et alertes du reste continuent.