🌐Infra: Websites, Datenbanken, Buckets, Domains, Server

Die Infra-Seite beantwortet die Fragen "Was liegt wo, und funktioniert es?": jede Website, Datenbank, jeder Bucket, jede Domain und jeder Server - auf diesem Server, auf deinen anderen Servern, bei Cloudflare und bei Hostinger - mit ihrem Status, ihren Verknüpfungen (diese Domain -> dieser Server -> diese Website -> diese App -> dieses Repository) und dem Harness-Projekt, zu dem sie gehört.

Sie ist standardmäßig ausgeschaltet: Schalte sie unter Einstellungen -> Funktionen -> Infra-Seite ein. In der Seitenleiste erscheint dann ein Eintrag Infra (Tastenkürzel G dann I).

So funktioniert es

Harness liest alles aus: diesen Server direkt, deine anderen Server über SSH (nur lesend), Cloudflare und Hostinger mit ihren API-Schlüsseln. Es verknüpft, was es findet: eine Domain mit ihrer Website, eine Website mit ihrer App, ihrer Datenbank und ihrem Git-Repository.
Es überwacht alles für dich: Jede Adresse wird geprüft (antwortet sie, ist ihr Zertifikat gültig), ebenso die Ablaufdaten der Domains und der Speicherplatz, alle 15 Minuten (infra_refresh_min) oder wenn du auf Aktualisieren klickst. Ein Problem erscheint ganz oben auf der Seite und in deinen Benachrichtigungen, einmal pro Vorfall.
Du erstellst Dinge, indem du Claude fragst: "Stell diesen Ordner online", "Erstelle eine Datenbank für meine App" ... Claude folgt den Standardrezepten (unten) und das Ergebnis erscheint auf der Seite.

Die Seite selbst verändert nie deine Websites oder Datenbanken; das Einzige, was sie von sich aus tut, ist einen Server zu verbinden (siehe Other servers). Um etwas zu ändern, frag Claude: Jede Zeile hat ein Feld Claude fragen.

Die Seite

Übersicht: ein Kasten "So funktioniert es" (mit einem Link zu dieser Seite) (schließe ihn mit ×, hol ihn oben rechts mit So funktioniert es zurück), die Anzahl jeder Art mit dem, was ausgefallen ist oder geprüft werden sollte, die Liste Zum Anschauen, und Was Harness liest: jede Quelle mit dem, was sie liefert, und, wenn etwas fehlt, dem nächsten Schritt (Schlüssel hinzufügen ..., Diese Rechte hinzufügen für einen Cloudflare-Token, der nicht alles lesen kann, Verbinden für einen noch nicht gelesenen VPS).
Websites, Datenbanken, Buckets, Domains: gruppiert danach, wo sie liegen. Domains -> Domain hinzufügen überwacht eine Domain bei einem beliebigen Registrar. Suchen, nach Projekt filtern, ausgeblendete Zeilen mit dem Augen-Button anzeigen.
Server: eine Karte pro Server mit seiner Adresse, seinem System, der genutzten Speicher-/Festplatten-/CPU-Auslastung und der Anzahl der Websites, Datenbanken und Buckets, die darauf laufen.
Klicke auf eine beliebige Zeile für ihre Details, ihre Verknüpfungen, ihr Repository (öffnet die Git-Seite), ihr Cloudflare-/Hostinger-Dashboard, ein Projekt, eine Notiz, zum Ausblenden oder um Claude dazu zu fragen.

Was gelesen wird

Quelle	Was du siehst	Benötigt
Dieser Server	Caddy- (oder nginx-)Websites und was hinter jeder steckt (Ordner, App-Port, systemd-Dienst, Docker-Container, Git-Repository), PostgreSQL-/MySQL-Datenbanken (auch in Docker), SQLite-Dateien, Garage-Buckets, Festplatte, Speicher	nichts
Deine anderen Server	dasselbe, über SSH gelesen	`python3` dort und SSH-Zugang: siehe Other servers
Jede Domain	Registrar und Ablaufdatum (öffentlicher RDAP-Dienst), wer ihr DNS bereitstellt (OVH, GoDaddy, Namecheap, IONOS, Gandi, o2switch ...), wer ihre Adresse hostet (einer deiner Server, Vercel, Netlify, GitHub Pages, Shopify, Cloudflare, Webflow, Wix, Squarespace ...)	nichts (öffentliches DNS); füge die Domains, die kein Anbieter auflistet, unter Domains -> Domain hinzufügen hinzu
Cloudflare	Domains (Zonen) und ihr DNS, Workers und ihre Adressen, Pages, R2-Buckets und ihre öffentlichen Adressen, D1-Datenbanken, Registrar-Domains	der Schlüssel `CLOUDFLARE_API_TOKEN` (+ `CLOUDFLARE_ACCOUNT_ID`)
Hostinger	Domains mit ihrem Ablaufdatum, VPS, DNS-Zonen	der Schlüssel `HOSTINGER_API_TOKEN`
Vercel (Beta)	Projekte mit ihrem Produktions-Deployment (Status, Datum, Git-Repository, Framework), ihre Domains; bei Vercel gekaufte Domains mit ihrem Ablaufdatum; jedes Team, das der Token sieht	der Schlüssel `VERCEL_TOKEN`
Netlify (Beta)	Websites mit ihrem letzten Deployment und Git-Repository, Netlify-DNS-Zonen	der Schlüssel `NETLIFY_AUTH_TOKEN`
Supabase (Beta)	jedes Projekt: seine Datenbank (Status, Region, Postgres-Version; ein pausiertes kostenloses Projekt zeigt "pausiert"), seine Storage-Buckets, seine Edge Functions, miteinander verknüpft	der Schlüssel `SUPABASE_ACCESS_TOKEN`
GitHub Pages (Beta)	die Pages-Websites deiner Repositories, ihre Adresse und ihr Build-Status	die GitHub-Tokens, die schon in deinen Schlüsseln sind (Git-Seite)

Schlüssel kommen unter Einstellungen -> Schlüssel (die Infra-Seite verlinkt dorthin). Harness liest damit nur. Vergib Leserechte, wo der Anbieter es erlaubt (Cloudflare, GitHub); Tokens von Vercel, Netlify und Supabase lassen sich nicht auf Lesen beschränken: Lass sie für Sessions nicht freigegeben (die Voreinstellung bei den Schlüsseln), damit nur die Infra-Seite sie benutzt. Fehlt einem Token eines der Rechte, wird nur dieser Teil ausgeblendet: Die Seite sagt dir, welcher.

Die öffentlichen DNS-Abfragen laufen über HTTPS über einen öffentlichen Resolver (standardmäßig 1.1.1.1 von Cloudflare): Er sieht die abgefragten Domainnamen, sonst nichts. Jeder Name wird höchstens alle 6 Stunden abgefragt.

Die Schlüssel erstellen

Cloudflare: dash.cloudflare.com/profile/api-tokens -> Token erstellen -> Benutzerdefiniert, Rechte (Lesen): Zone, DNS, Workers Scripts, Workers Routes, Cloudflare Pages, Workers R2 Storage, D1, Registrar; füge DNS Edit hinzu, wenn Claude DNS-Einträge für neue Websites anlegen soll.
Hostinger: hPanel -> Profil -> API -> neuer Token.
Vercel: vercel.com/account/settings/tokens -> Token erstellen, Bereich "Full account", um jedes Team zu sehen (Vercel hat keinen reinen Lese-Token: Harness liest nur).
Netlify: User settings -> Applications -> Personal access tokens -> New access token.
Supabase: supabase.com/dashboard/account/tokens -> Neuen Token generieren.
GitHub Pages: nichts weiter, wenn die Git-Seite deine Repositories schon anzeigt.

Beta bedeutet: nach der offiziellen API-Referenz des Anbieters geschrieben und gegen seine dokumentierten Antworten getestet, aber noch nicht an einem echten Konto gesehen. Wenn eine Zeile einen Fehler zeigt, frag Claude direkt von dieser Zeile aus (er sieht den Fehler) und sag uns Bescheid.

Mein Anbieter ist nicht aufgeführt

Domains: Es ist nichts nötig. Füge die Domain unter Domains -> Domain hinzufügen hinzu (oder sag Claude "überwache die Domain example.com"): Ihr Registrar, Ablaufdatum, DNS-Anbieter und Host werden aus öffentlichen Informationen gelesen, und sie wird mit deinem Server verknüpft, wenn sie darauf zeigt. Warnungen vor dem Ablauf funktionieren genauso.
Ein Server (OVH, DigitalOcean, Hetzner, Scaleway ...): Server hinzufügen, er wird wie jeder andere über SSH gelesen.
Eine Plattform (Render, Railway, Fly.io, Firebase, AWS ...): Ihre Websites erscheinen trotzdem über ihre Domains (die Seite sagt, wer jede Adresse hostet). Volle Unterstützung ist Anbieter für Anbieter geplant.

Andere Server

Ein Hostinger-VPS erscheint von selbst, sobald der Hostinger-Schlüssel im Tresor liegt, unter dem Namen VPS Hostinger. Wenn er bereits einen SSH-Schlüssel dieses Servers akzeptiert, verbindet Harness ihn von selbst (die Hostinger-API sagt, welcher Schlüssel, es wird also nichts blind ausprobiert). Andernfalls öffne ihn und klicke auf Verbinden: Harness fügt seinen eigenen Schlüssel (harness-maxxing@<this server>) über deinen Hostinger-Schlüssel zum root-Konto des VPS hinzu und liest ihn dann aus. Das ist die einzige Änderung, die die Infra-Seite bei einem Anbieter vornimmt; du kannst den Schlüssel in hPanel -> VPS -> SSH-Schlüssel entfernen.
Jeder andere Server: Server hinzufügen (oben auf der Seite) mit seiner Adresse, dem SSH-Benutzer und dem Port. Wenn dort keiner der Schlüssel dieses Servers akzeptiert wird, zeigt dir das Fenster eine Zeile, die du auf diesem Server ausführen musst, dann Erneut versuchen.
Im Panel eines verbundenen Servers: Ändere den angezeigten Namen (der interne Name, der in Links verwendet wird, ändert sich nie) oder trenne ihn (auf dem Server ändert sich nichts).
Im Terminal: maxxing infra server connect <IP or Hostinger VPS id>, server rename NAME "Label".

Harness liest die anderen Server nur (Websites, Ports und Dienste, Docker, Datenbanken, Buckets, Festplatte, Speicher). Der Server braucht python3 (jedes gängige Linux hat es).

Status

OK (grün), Zu prüfen (orange): eine Seite, die mit 404 antwortet, ein bald ablaufendes Zertifikat oder eine bald ablaufende Domain, ein DNS-Eintrag, der auf einen anderen Server zeigt als den, der die Website ausliefert, eine fast volle Festplatte, ein fehlgeschlagenes Backup ...
Ausgefallen (rot): keine Antwort, ein Serverfehler (5xx), eine abgelaufene Domain, eine von einem Rezept erstellte Ressource, die nicht mehr gefunden werden kann.

Warnungen gehen an den Benachrichtigungs-Feed (und an Telegram, wenn dessen Feed-Thread eingeschaltet ist): eine Website oder ein Server, der ausfällt und wieder erreichbar ist, ein Zertifikat, das innerhalb von 14 Tagen abläuft, eine Domain, die innerhalb von 30 und dann 7 Tagen abläuft (wenn sie nicht automatisch verlängert wird).

Dinge auf diesem Server erstellen

Frag Claude in einfachen Worten; er folgt einem festen Rezept (Skill maxxing-infra, Befehl maxxing infra), damit alles auf dieselbe Weise erledigt, vor der Anwendung geprüft wird und auf der Seite erscheint:

"Stell diesen Ordner online" -> https://<your Harness address>/<name>/, sofort, ohne DNS. Diese Seiten laufen isoliert (in einer Sandbox): Sie können nie Harness oder deine Session berühren (eine App hinter so einem Pfad erhält nie dein Harness-Cookie und kann auch keins setzen; versteckte Dateien wie .env oder .git werden nie ausgeliefert; das Workspace-Stammverzeichnis, der Code, der Statusordner und .ssh können nicht veröffentlicht werden). Ideal für Seiten, Demos, Berichte, statische Websites. Eine App mit Login, Warenkorb oder Cookies braucht ihre eigene Adresse (shop.example.com): Claude rät dazu und legt den DNS-Eintrag bei Cloudflare an, wenn der Schlüssel es erlaubt.
"Erstelle eine Datenbank für meine App" -> PostgreSQL (beim ersten Mal installiert, nur von diesem Server aus erreichbar), eine Datenbank und ein Benutzer pro App, ihre Adresse wird unter Schlüssel gespeichert (DB_<NAME>_URL), jede Nacht gesichert (Job "Infra: database backups", 7 Kopien werden in /var/backups/maxxing-db aufbewahrt).
"Erstelle einen Bucket" -> S3-Speicher auf diesem Server (Garage), seine Schlüssel unter Schlüssel (S3_<NAME>_...), optional öffentlich unter https://<your Harness address>/<name>/. Die Dateien bleiben auf dieser Festplatte: Für große öffentliche Dateien ist Cloudflare R2 oft besser, Claude sagt es dir.
"Füge meinen anderen Server 203.0.113.7 hinzu" -> Claude verbindet ihn (maxxing infra server connect); wenn er noch keinen Schlüssel dieses Servers akzeptiert, sagt Claude dir die Zeile, die du dort ausführen musst.

In Unterhaltungen

Wenn Claude über Ressourcen spricht, fügt er einen kleinen infra-Block hinzu, den die App live anzeigt (Status, Link zur Seite):

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

Zeilen: site, database, bucket, domain, server, worker, pages, id (je eine Ressource) oder Filter project: acme, kind: database, location: <server>. Wird angezeigt, wenn die Infra-Seite eingeschaltet ist (sonst bleibt der Text stehen).

Terminal

Sicherheit von `infra.json`

Die Server in <workspace>/infra.json werden vom Server selbst über ssh erreicht, deshalb darf Claude diese Datei nicht bearbeiten (sie steht in den Deny-Regeln jedes Durchgangs, wie die Ordnereinstellungen); nutze maxxing infra server add oder die Seite. Ein von Hand geschriebener Eintrag, den die CLI ablehnen würde (ungewöhnlicher Benutzer, Host oder Schlüsselpfad), wird ignoriert. Ein Anbieter, der nicht antwortet (Cloudflare, Hostinger, ein Server), lässt nur seinen eigenen Bereich leer: Die Prüfungen und Warnungen für den Rest laufen weiter.