Plataforma interna: GitLab, Kubernetes, Coolify o Dokploy
La base sobre la que vuestro equipo construye y despliega, montada en vuestra cuenta, en código y con un procedimiento para que cualquiera publique un servicio nuevo.
Herramientas habituales
- Coolify
- Dokploy
- Gitea
- GitLab
- Kafka
- Keycloak
- Kubernetes
- Hetzner
En resumen
Una plataforma interna es el conjunto de herramientas con el que vuestro equipo guarda el código, lo construye y lo despliega sin pedir ayuda. Montamos GitLab autoalojado con runners y registry, un clúster de Kubernetes o k3s, o un PaaS autoalojado como Coolify o Dokploy cuando Kubernetes es demasiado. Todo queda en vuestra cuenta, en código y documentado.
- Idiomas
- Español, catalán o inglés
- Respuesta
- El siguiente día hábil, en horario laboral
- Método
- En vuestra cuenta y vuestro repositorio, en código y documentado
Qué incluye
- Arquitectura elegida por escrito, con el motivo y las alternativas descartadas.
- GitLab autoalojado con runners, registry de contenedores y almacenamiento de objetos, si encaja.
- Clúster de Kubernetes o k3s, o PaaS con Coolify o Dokploy, desplegado con código.
- Plantilla para publicar un servicio nuevo: pipeline, despliegue, dominio y certificado.
- Copias de la plataforma con restauración probada.
- Monitorización básica de la propia plataforma.
- Acceso del equipo técnico por VPN WireGuard, con una clave por persona.
- Documentación y sesión de traspaso con el equipo.
¿Cuándo hace falta una plataforma interna?
Cuando desplegar depende de una persona o de un documento desactualizado. Estas son las señales más habituales:
- Cada proyecto se despliega de una forma distinta y solo una persona sabe cómo.
- El GitLab o el Gitea de la casa lleva años sin actualizarse y nadie quiere tocarlo.
- Los minutos de CI en la nube o las licencias por usuario se han vuelto una partida importante.
- Queréis dejar de depender de un PaaS comercial y tener los servicios en vuestra cuenta.
- Cada cliente de la agencia tiene su servidor montado a mano.
¿Kubernetes, k3s o un PaaS autoalojado?
No hay una respuesta única: depende de cuántos servicios tenéis, de cuántos entornos necesitáis y de quién va a mantenerlo. Esta es la comparación que solemos hacer con cada equipo:
| Opción | Encaja cuando | Lo que pide a cambio | Lo que no hace bien |
|---|---|---|---|
| Kubernetes gestionado (EKS, GKE, AKS) | Muchos servicios, varios entornos y alta disponibilidad | Conocimiento de Kubernetes y vigilancia del coste | Equipos de dos personas con tres aplicaciones |
| k3s en vuestros servidores | Kubernetes en Hetzner u otro proveedor sin servicio gestionado | Mantener vosotros el plano de control y las actualizaciones | Escalar a decenas de nodos sin más diseño |
| Coolify o Dokploy | Pocas aplicaciones, uno o dos servidores, equipo pequeño | Aceptar sus límites de red y de alta disponibilidad | Políticas de seguridad finas y multiclúster |
| Docker Compose con CI | Una o dos aplicaciones estables | Disciplina en el pipeline y en las copias | Despliegues sin corte y escalado automático |
La recomendación queda por escrito, con el motivo. Si Kubernetes es demasiado para vuestro equipo, os lo decimos.
¿Qué montamos con GitLab?
Cuando la plataforma gira en torno a GitLab autoalojado, nos ocupamos de las piezas que suelen dar problemas: los runners con caché y escalado, el registry de contenedores con limpieza automática de imágenes, el almacenamiento de objetos para artefactos y paquetes, el inicio de sesión único con vuestro proveedor de identidad y las copias con restauración probada. Lo detallamos en la página de GitLab self-hosted gestionado.
El acceso del equipo técnico a los paneles, las bases de datos y los servidores internos va por una VPN WireGuard, con una clave por persona que se revoca al momento, sin puertos de administración abiertos a internet.
¿Cómo se trabaja el proyecto?
Es un proyecto cerrado, con entregables por escrito antes de empezar:
Inventario
Qué aplicaciones hay, cómo se despliegan hoy, qué entornos necesitáis y qué restricciones tenéis de datos o de proveedor.
Diseño
Arquitectura elegida, alternativas descartadas y coste aproximado de la infraestructura en vuestro proveedor.
Montaje en código
Terraform o Ansible para la infraestructura, Helm o los manifiestos del PaaS para los servicios, todo en vuestro repositorio.
Primer servicio
Migramos una aplicación real de punta a punta y la usamos de plantilla para las demás.
Traspaso
Documentación, sesión con el equipo y, si queréis, mantenimiento con la cuota de SRE.
¿Qué experiencia tenemos con plataformas?
Desde la dirección técnica hemos montado y mantenido la plataforma de varias startups, con despliegues en contenedores y una disponibilidad del 99,9 %. Como DevOps en un SaaS B2B hemos trabajado con entornos multinube descritos en código y pipelines de CI/CD que desplegaban varias veces al día. Lo que hemos aprendido: una plataforma solo funciona si el equipo la entiende y la usa sin pedir permiso.
Preguntas frecuentes
¿Por qué autoalojar GitLab en lugar de usar el de la nube?
Suele compensar cuando el código no puede salir de vuestra infraestructura, cuando los minutos de CI en la nube se disparan o cuando necesitáis runners con hardware propio. Si no se da ninguna de esas razones, os recomendaremos el servicio en la nube.
¿Coolify o Dokploy sirven para producción?
Sí, para equipos pequeños con pocas aplicaciones y un par de servidores. A partir de muchos servicios, varios entornos o requisitos de alta disponibilidad, Kubernetes o k3s suelen ser mejor opción. Os explicamos dónde está el límite en vuestro caso.
¿Quién mantiene la plataforma después?
Vuestro equipo, con la documentación que dejamos, o nosotros con la cuota de SRE como servicio. La plataforma no depende de nosotros: está en vuestra cuenta y en vuestro repositorio.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Revisado el