Qué es esto
Esta página es la corta: la lectura de cinco minutos. La larga, con los treinta servicios uno a uno, es el catálogo: [[entity—ops—catalogo-servicios-externos]]. No son dos versiones de lo mismo: esta explica y aquella se consulta.
CreaRack no corre solo en nuestros servidores: depende de una veintena larga de servicios, unos contratados a terceros (Cloudflare, GitHub, Google AI Studio, Zoho, Holded, Stripe…) y otros nuestros (Dokploy, Forgejo, VictoriaMetrics, la vigilancia de operaciones…). A ese conjunto lo llamamos el stack de servicios. Esta página es la puerta de entrada: dónde está el mapa, cómo se mantiene al día y qué plan tenemos con él.
Las dos cosas que hay que conocer
- El catálogo → [[entity—ops—catalogo-servicios-externos]]. Es la fuente de verdad: para cada servicio, qué hace, quién lo paga y cuánto, qué pasa si cae y en cuánto tiempo se nota, dónde viven sus credenciales, qué caduca, y si tiene alternativa open source. Trae además un mapa de dependencias (quién depende de quién) y la tabla “si esto cae, cae el negocio”.
- El plan en tres tiempos (10-09-2026, task #298; documento completo en el repo del workspace,
public/supercontext/stack-servicios/PLAN_STACK_SERVICIOS.md):- Tiempo 1 · el mapa vivo — HECHO: el catálogo se refrescó con datos reales y, desde ese día, un inventario automático corre cada lunes en el servidor de operaciones, lee lo que las APIs y los servidores saben, y manda un correo a
infra@si aparece o desaparece cualquier cosa o si algo caduca en menos de un mes. Lo “vivo” ya no depende de que alguien se acuerde. - Tiempo 2 · la estrategia: decidir qué servicios de terceros pasamos a hospedar nosotros (NetBird, la vigilancia externa, Forgejo como origen del código, cuántas máquinas y con qué papeles). Es una decisión de negocio y se toma con investigación y consejo crítico, no de oídas.
- Tiempo 3 · las migraciones, una a una, cada una con su plan revisado, su apuesta y su marcha atrás probada.
- Tiempo 1 · el mapa vivo — HECHO: el catálogo se refrescó con datos reales y, desde ese día, un inventario automático corre cada lunes en el servidor de operaciones, lee lo que las APIs y los servidores saben, y manda un correo a
El principio que no cambia
Hospedamos lo que es nuestro; el perímetro (DNS, CDN, protección de ataques), el correo, la contabilidad y los cobros se quedan en terceros. Y un solo servidor grande es un solo fallo: si cae, caen a la vez la VPN, el código, el CI y la vigilancia, y la VPN es justo la puerta para ir a arreglarlo. Mejor máquinas pequeñas con papeles claros y el salvavidas de acceso siempre fuera de ellas.
Cuando llegue el correo del lunes
El correo “[stack-inventario] N cambios · M caducidades” lista lo que ha aparecido o desaparecido. Si el cambio es esperado (un servidor nuevo, un cron, un token renovado), se refleja en el catálogo el mismo día. Si no lo es, se investiga antes de tocar nada. Quien conduce la sesión en que llega el aviso es quien lo atiende.
Véase también
- [[entity—ops—catalogo-servicios-externos]] · [[workspace—infra—servidor-ops]] · [[workspace—guias—team-processes]] (§8 cuentas de servicio)
public/supercontext/AUTOMATISMOS.md(todos los crons) ·claude-method/guides/NETBIRD_SETUP.md(la red privada)