Mucho OSS es open source en código, hosted only en práctica. Cuando intentas self-hostarlo, te quedas sin soporte, te enfrentas a deps no documentadas, y la build pasa rota por días.
OpenDome es lo contrario · self-host first. El producto se diseña primero para correr en tu cluster. El SaaS, cuando exista, será un wrapper, no la única ruta.
Cinco implicaciones operativas
- Las builds OSS van primero. Cada release pasa por una pipeline self-host antes de salir. Si no funciona en self-host, no se publica.
- Los manifests Kubernetes están en el repo. No "ejemplos" — los reales, los que usamos nosotros.
- Hardening por defecto. TLS, secrets, network policies vienen activos. Si tienes que desactivarlos, hay un motivo documentado.
- DR plan documentado. Backup, restore, runbooks · todo en el repo, no en un wiki interno.
- Soporte OSS real. Las issues de self-host se trataan igual que las de cloud — el equipo responde, los bugs se arreglan.
Lo que no significa
No significa que sea fácil. Self-host first no es self-host trivial. Necesitas un equipo de plataforma con experiencia en Kubernetes, observabilidad y operativa diaria. El Self-host Handbook cubre el playbook completo.