🌐Infra: sitios, bases de datos, buckets, dominios, servidores

La página Infra responde a «¿dónde está cada cosa y funciona?»: cada sitio, base de datos, bucket, dominio y servidor - en este servidor, en tus otros servidores, en Cloudflare y en Hostinger - con su estado, sus vínculos (este dominio -> este servidor -> este sitio -> esta app -> este repositorio) y el proyecto de Harness al que pertenece.

Está desactivada por defecto: actívala en Ajustes -> Funciones -> Página Infra. Aparece una entrada Infra en la barra lateral (atajo G y luego I).

Cómo funciona

Harness lo lee todo: este servidor directamente, tus otros servidores por SSH (solo lectura), Cloudflare y Hostinger con sus claves de API. Vincula lo que encuentra: un dominio con su sitio, un sitio con su app, su base de datos y su repositorio git.
Lo vigila por ti: se comprueba cada dirección (si responde, si su certificado es válido), así como las fechas de caducidad de los dominios y el espacio en disco, cada 15 minutos (infra_refresh_min) o cuando haces clic en Actualizar. Un problema aparece arriba de la página y en tus notificaciones, una sola vez por incidente.
Creas pidiéndoselo a Claude: «pon esta carpeta en línea», «crea una base de datos para mi app»... Claude sigue las recetas estándar (más abajo) y el resultado aparece en la página.

La página en sí nunca modifica tus sitios ni tus bases de datos; lo único que hace por sí sola es conectar un servidor (consulta Otros servidores). Para cambiar algo, pídeselo a Claude: cada línea tiene un cuadro Preguntar a Claude.

La página

Resumen: un cuadro «Cómo funciona» (con un enlace a esta página) (ciérralo con ×, vuelve a mostrarlo con Cómo funciona arriba a la derecha), el recuento de cada tipo con lo que está caído o por revisar, la lista Para revisar, y Lo que lee Harness: cada fuente con lo que aporta y, cuando falta algo, el siguiente paso (Añadir la clave ..., Añadir estos permisos para un token de Cloudflare que no puede leerlo todo, Conectar para un VPS que aún no se ha leído).
Sitios, Bases de datos, Buckets, Dominios: agrupados según dónde viven. Dominios -> Añadir un dominio vigila un dominio de cualquier registrador. Busca, filtra por proyecto, muestra las líneas ocultas con el botón del ojo.
Servidores: una tarjeta por servidor con su dirección, su sistema, la memoria / disco / CPU en uso y cuántos sitios, bases de datos y buckets funcionan en él.
Haz clic en cualquier línea para ver sus detalles, con qué está vinculada, su repositorio (abre la página Git), su panel de Cloudflare / Hostinger, un proyecto, una nota, para ocultarla, o para preguntarle a Claude sobre ella.

Qué lee

Fuente	Qué ves	Requiere
Este servidor	Sitios de Caddy (o nginx) y lo que hay detrás de cada uno (carpeta, puerto de la app, servicio systemd, contenedor Docker, repositorio git), bases de datos PostgreSQL / MySQL (también dentro de Docker), archivos SQLite, buckets de Garage, disco, memoria	nada
Tus otros servidores	lo mismo, leído por SSH	`python3` en ellos y acceso SSH: consulta Otros servidores
Cualquier dominio	registrador y fecha de caducidad (servicio público RDAP), quién sirve su DNS (OVH, GoDaddy, Namecheap, IONOS, Gandi, o2switch...), quién aloja su dirección (uno de tus servidores, Vercel, Netlify, GitHub Pages, Shopify, Cloudflare, Webflow, Wix, Squarespace...)	nada (DNS público); añade los dominios que ningún proveedor lista en Dominios -> Añadir un dominio
Cloudflare	dominios (zonas) y su DNS, Workers y sus direcciones, Pages, buckets R2 y sus direcciones públicas, bases de datos D1, dominios de Registrar	la clave `CLOUDFLARE_API_TOKEN` (+ `CLOUDFLARE_ACCOUNT_ID`)
Hostinger	dominios con su fecha de caducidad, VPS, zonas DNS	la clave `HOSTINGER_API_TOKEN`
Vercel (beta)	proyectos con su despliegue de producción (estado, fecha, repositorio git, framework), sus dominios; dominios comprados en Vercel con su fecha de caducidad; todos los equipos que ve el token	la clave `VERCEL_TOKEN`
Netlify (beta)	sitios con su último despliegue y repositorio git, zonas DNS de Netlify	la clave `NETLIFY_AUTH_TOKEN`
Supabase (beta)	cada proyecto: su base de datos (estado, región, versión de Postgres; un proyecto gratuito en pausa muestra «en pausa»), sus buckets de Storage, sus Edge Functions, todo vinculado	la clave `SUPABASE_ACCESS_TOKEN`
GitHub Pages (beta)	los sitios Pages de tus repositorios, su dirección y el estado de la compilación	los tokens de GitHub que ya tienes en tus claves (página Git)

Las claves se guardan en Ajustes -> Claves (la página Infra enlaza a ellas). Harness solo lee con ellas. Da permisos de solo lectura donde el proveedor lo permita (Cloudflare, GitHub); los tokens de Vercel, Netlify y Supabase no se pueden limitar a lectura: déjalos sin exponer a las sesiones (lo predeterminado en Claves) para que solo los use la página Infra. Un token al que le falte alguno de los permisos solo oculta esa parte: la página te dice cuál.

Las consultas de DNS público pasan por un resolvedor público mediante HTTPS (el 1.1.1.1 de Cloudflare por defecto): ve los nombres de dominio consultados, nada más. Cada nombre se consulta como máximo cada 6 horas.

Crear las claves

Cloudflare: dash.cloudflare.com/profile/api-tokens -> Create token -> Custom, permisos (Read): Zone, DNS, Workers Scripts, Workers Routes, Cloudflare Pages, Workers R2 Storage, D1, Registrar; añade DNS Edit si quieres que Claude cree registros DNS para sitios nuevos.
Hostinger: hPanel -> Perfil -> API -> nuevo token.
Vercel: vercel.com/account/settings/tokens -> Create token, ámbito «Full account» para ver todos los equipos (Vercel no tiene token de solo lectura: Harness solo lee).
Netlify: User settings -> Applications -> Personal access tokens -> New access token.
Supabase: supabase.com/dashboard/account/tokens -> Generate new token.
GitHub Pages: nada más si la página Git ya muestra tus repositorios.

Beta significa escrito a partir de la referencia oficial de la API del proveedor y probado con sus respuestas documentadas, pero aún no visto en una cuenta real: si una línea muestra un error, pregúntale a Claude desde esa línea (ve el error) y cuéntanoslo.

Mi proveedor no aparece

Dominios: no hace falta nada. Añade el dominio en Dominios -> Añadir un dominio (o dile a Claude «vigila el dominio example.com»): su registrador, fecha de caducidad, proveedor de DNS y alojamiento se leen de información pública, y se vincula a tu servidor cuando apunta a él. Las alertas antes de la caducidad funcionan igual.
Un servidor (OVH, DigitalOcean, Hetzner, Scaleway...): Añadir un servidor, se lee por SSH como cualquier otro.
Una plataforma (Render, Railway, Fly.io, Firebase, AWS...): sus sitios aun así aparecen a través de sus dominios (la página indica quién aloja cada dirección). El soporte completo está previsto proveedor por proveedor.

Otros servidores

Un VPS de Hostinger aparece solo en cuanto la clave de Hostinger está en la bóveda, con el nombre VPS Hostinger. Si ya acepta una clave SSH de este servidor, Harness lo conecta por sí mismo (la API de Hostinger indica qué clave, así que no se prueba a ciegas). Si no, ábrelo y haz clic en Conectar: Harness añade su propia clave (harness-maxxing@<this server>) a la cuenta root del VPS a través de tu clave de Hostinger y luego lo lee. Es el único cambio que la página Infra hace en un proveedor; puedes quitar la clave en hPanel -> VPS -> Claves SSH.
Cualquier otro servidor: Añadir un servidor (arriba de la página) con su dirección, usuario SSH y puerto. Si ninguna de las claves de este servidor es aceptada allí, la ventana te da una línea para ejecutar en ese servidor y luego Reintentar.
En el panel de un servidor conectado: cambia el nombre mostrado (el nombre interno, usado en los vínculos, nunca cambia) o Desconéctalo (no cambia nada en el servidor).
Desde el terminal: maxxing infra server connect <IP or Hostinger VPS id>, server rename NAME "Label".

Harness solo lee los otros servidores (sitios, puertos y servicios, Docker, bases de datos, buckets, disco, memoria). El servidor necesita python3 (cualquier Linux habitual lo tiene).

Estados

OK (verde), Por revisar (naranja): una página que responde 404, un certificado o un dominio a punto de caducar, un registro DNS que apunta a otro servidor distinto del que sirve el sitio, un disco casi lleno, una copia de seguridad fallida...
Caído (rojo): sin respuesta, un error de servidor (5xx), un dominio caducado, un recurso creado por una receta que ya no se encuentra.

Las alertas van al feed de notificaciones (y a Telegram cuando su hilo de feed está activado): un sitio o un servidor que se cae y vuelve a funcionar, un certificado que caduca en menos de 14 días, un dominio que caduca en 30 y luego en 7 días (cuando no se renueva automáticamente).

Crear cosas en este servidor

Pídeselo a Claude con palabras sencillas; sigue una receta fija (skill maxxing-infra, comando maxxing infra) para que todo se haga siempre igual, se compruebe antes de aplicarse y aparezca en la página:

«Pon esta carpeta en línea» -> https://<your Harness address>/<name>/, al instante, sin DNS. Estas páginas se ejecutan aisladas (en un sandbox): nunca pueden tocar Harness ni tu sesión (una app detrás de una ruta así nunca recibe tu cookie de Harness y no puede establecer una; los archivos ocultos como .env o .git nunca se sirven; la raíz del workspace, el código, la carpeta de estado y .ssh no se pueden publicar). Perfecto para páginas, demos, informes, sitios estáticos. Una app con inicio de sesión, un carrito o cookies necesita su propia dirección (shop.example.com): Claude te lo aconseja y crea el registro DNS en Cloudflare cuando la clave lo permite.
«Crea una base de datos para mi app» -> PostgreSQL (instalado la primera vez, accesible solo desde este servidor), una base de datos y un usuario por app, su dirección guardada en Claves (DB_<NAME>_URL), con copia de seguridad cada noche (tarea «Infra: database backups», 7 copias guardadas en /var/backups/maxxing-db).
«Crea un bucket» -> almacenamiento S3 en este servidor (Garage), sus claves en Claves (S3_<NAME>_...), opcionalmente público en https://<your Harness address>/<name>/. Los archivos se quedan en este disco: para archivos públicos grandes, Cloudflare R2 suele ser mejor, y Claude te lo dice.
«Añade mi otro servidor 203.0.113.7» -> Claude lo conecta (maxxing infra server connect); si todavía no acepta una clave de este servidor, Claude te dice la línea que debes ejecutar allí.

En las conversaciones

Cuando Claude habla de recursos, añade un pequeño bloque infra que la app muestra en vivo (estado, enlace a la página):

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

Líneas: site, database, bucket, domain, server, worker, pages, id (un recurso cada una), o filtros project: acme, kind: database, location: <server>. Se muestra cuando la página Infra está activada (si no, el texto se queda tal cual).

Terminal

Seguridad de `infra.json`

Los servidores de <workspace>/infra.json son alcanzados mediante ssh por el propio servidor, así que Claude no puede editar ese archivo (está en las reglas de denegación de cada turno, como los ajustes de carpeta); usa maxxing infra server add o la página. Una entrada escrita a mano que la CLI rechazaría (usuario, host o ruta de clave extraños) se ignora. Un proveedor que no responde (Cloudflare, Hostinger, un servidor) solo deja vacía su propia sección: las comprobaciones y alertas del resto continúan.