Durante más de 20 años el equipo del que formo parte ha estado ayudando a organizaciones a construir y operar plataformas de software. Han sido dos décadas llenas de lecciones. Las más importantes:
- Construir software es duro. Un sistema con interdependencias es difícil de crear y mantener; sin una arquitectura clara, es todavía más difícil.
- La creación de software se parece más al proceso productivo del mundo físico de lo que creemos: sin controlar la fábrica no se pueden crear grandes productos.
- La plataforma debe ser un servicio más dentro de la organización. Su desempeño condiciona directamente la eficacia de los desarrolladores.
El corolario es claro: la plataforma tiene que garantizar self-service y gobernanza al mismo tiempo.
Durante años aplicamos estas lecciones como diseñadores y mantenedores de plataforma en distintas organizaciones. Pronto vimos que necesitábamos una herramienta que nos facilitara adaptar y estandarizar ese trabajo. Y que tenía sentido hacerla open source.
Firestartr es el resultado.
Un proyecto open source que convierte el modelo de tu organización (dominios, sistemas, componentes, equipos e infraestructura) en la fuente de verdad de la plataforma. Self-service real + gobernanza integrada.
Un modelo explícito para construir tu Internal Developer Platform
Cualquier organización que tenga software a su cargo se encontrará con un conjunto de repositorios, pipelines y entornos desplegados que, con el tiempo y el crecimiento de la plantilla, se convierten en un laberinto de difícil gestión.
Una de las principales razones para esto es que la complicada red de relaciones que se forma naturalmente entre todas estas piezas está, y solo parcialmente, “en la cabeza” de aquellos que llevan más tiempo: esto es, son relaciones implícitas que solo se pueden entender y conocer cuando se lleva tiempo en la organización.
- ❌ Efecto «Tribal Knowledge»: El onboarding de nuevos desarrolladores se vuelve lento y doloroso. Entender qué hace un servicio o cómo se conecta con otros requiere consultar a «los que llevan más tiempo».
- ❌ Fragilidad operativa: Cuando un ingeniero sénior abandona la organización, se pierde parte de la cartografía invisible de la infraestructura.
- ❌ Miedo al cambio: Nadie se atreve a refactorizar o apagar un componente porque nadie está seguro de cuáles son los sistemas dependientes del mismo ni de los efectos colaterales que puede tener su alteración / supresión.
Hemos vivido esta “cultura opaca” en primera persona. Por eso diseñamos Firestartr para que las relaciones dejen de estar solo en la cabeza de la gente y pasen a estar en el modelo.
Nuestro enfoque combina la visión del DDD (Domain-Driven-Design) con la jerarquía estructural del modelo C4 para alcanzar un modelado similar al del catálogo de software de backstage.
- Dominios — Áreas de responsabilidad de la organización.
- Sistemas — Conjuntos coordinados de software que resuelven un problema concreto de negocio dentro de un dominio.
- Componentes — Piezas atómicas de software (normalmente un repositorio). Se empaquetan, despliegan, escalan y monitorizan.
- Equipos — Entidades humanas responsables del ciclo de vida completo de un sistema y/o de sus componentes.
¿En qué se diferencia de Backstage + Argo + Terraform?
📚 Backstage te da el catálogo.
🔄 Argo CD te da la reconciliación continua.
🏗️ Terraform te da la infraestructura.
🧩 Firestartr une las tres bajo un mismo modelo de ownership y de claims.
Un cambio de ownership, un nuevo componente o un workspace de Terraform dejan de ser tres herramientas distintas: son declaraciones que el motor entiende y aplica de forma consistente.
¿Qué ocurre con el aprovisionamiento de servicios cloud?
Terraform se ha convertido en la lengua franca del aprovisionamiento cloud.
Firestartr trata un servicio (o un conjunto inseparable de servicios) provisionado con Terraform/OpenTofu como un Terraform Workspace de primer nivel (y se modela como tal en el catálogo de la organización). Tratar los Terraform Workspaces como recursos explícitos en el modelo resuelve el abismo entre la infraestructura y la aplicación:
- ✅ Aislamiento de Estado por Entorno: Cada componente declara explícitamente su Workspace de Terraform (payment-processor-prod, payment-processor-staging), con un backend state aislado y gestionado por la plataforma.
- ✅ Inyección Controlada de Variables: Las credenciales y variables de entorno del Workspace se resuelven de forma segura mediante políticas de plataforma, sin exponer secretos en repositorios application-level.
- ✅ Ciclo de vida unificado: Cuando un componente se elimina mediante un claim, el Terraform Workspace asociado se destruye de forma controlada.
Evitamos así los recursos huérfanos que quedan olvidados en la nube y siguen generando coste.
Motor GitOps: el corazón de la fábrica
GitOps se ha consolidado como el estándar de los IDPs. Git como única fuente de verdad, cambios mediante Pull Requests y reconciliación continua.
Firestartr construye su motor sobre este principio, pero de forma deliberadamente simple:
- Todo es un claim. Un fichero YAML en un repositorio declara la intención: un componente, un sistema, un equipo o un workspace de Terraform. No hay estado oculto.
- El renderer es un pipeline ligero. Valida, hidrata y completa cada claim con los defaults y las políticas de la organización. Produce Custom Resources y entidades de catálogo listos para ser reconciliados.
- El Operator + Argo CD hacen el resto. Observan, sincronizan y provisionan. Reutilizan Kubernetes, Git y OpenTofu en lugar de reinventar un control plane pesado.
El resultado es un motor que cualquiera puede seguir:
declaras → se renderiza → se reconcilia → aparece en GitHub y en la nube.
Simple de entender. Ligero de operar. Completo en lo que entrega.
El stitching: el entrelazado de las intenciones de distintas fuentes
La experiencia con GitOps nos ha enseñado tres principios determinantes:
- El usuario debe poder expresar su intención de la forma más breve posible y con el menor número de opciones.
- Los defaults son la base: representan el plano arquitectónico estándar, seguro y gobernado que la plataforma aplica automáticamente.
- Deben existir políticas globales (obligatorias para todos) que nadie pueda contradecir.
Firestartr combina estas tres fuentes declarativas con una prelación clara:
- Usuario — Declara la intención fundamental: crear un componente, aprovisionar una base de datos, añadir un usuario a un equipo…
- Defaults — La plataforma completa y uniforma esa declaración con los valores estándar definidos por la organización.
- Globals — Directivas obligatorias que prevalecen sobre todo lo anterior. Son la cumbre de la pirámide y no pueden ser anuladas.
El resultado es que la definición real de cualquier artefacto nace de estas tres capas, respetando siempre su orden de prioridad. El usuario escribe poco; la plataforma garantiza coherencia y gobernanza.
Open source y servicio de Prefapp
Firestartr es Apache-2.0. Todo el código del motor está en:
→ github.com/firestartr-pro/firestartr
Prefapp mantiene el proyecto y ofrece servicios profesionales:
diseño e implantación, adaptación de features y políticas, soporte y skills listas para usar.
La distinción es deliberada:
- Firestartr → el código y el modelo, sin vendor lock-in.
- Prefapp → experiencia y resultados contractuales.
Si quieres probarlo, empieza por la documentación: docs.firestartr.dev.
Te ayudamos a implantarlo, habla con nosotros.