641 estrellas y 109 forks en sus primeros 13 días: Zeabur se publicó en GitHub el 24 de octubre de 2026 y el 5 de noviembre seguía recibiendo commits. Es una PaaS autoalojada que se instala sobre tu propio Kubernetes, y su promesa es llamativa por lo que no hace: no tiene base de datos, no crea recursos personalizados (CRD) y nunca actúa con más permisos que la persona que la usa.
Qué es y cómo funciona
Zeabur enseña el clúster como proyectos y servicios, en lugar de como namespaces y Deployments. Cada proyecto tiene su mapa de servicios, bases de datos y conexiones; cada servicio, su despliegue en curso, el consumo de CPU y memoria frente a los límites y si sus dominios responden. Cuando algo falla, por ejemplo un servicio que se reinicia en bucle, da un diagnóstico en lenguaje claro, con qué hacer y la evidencia. Y antes de crear un servicio nuevo enseña el YAML del Deployment, el Service y el Ingress que va a aplicar.
La decisión de diseño que más me interesa es que no guarda estado propio. Trabaja sobre los objetos estándar de Kubernetes que ya tienes y lee el clúster con el token de la persona que ha iniciado sesión, no con una cuenta de servicio todopoderosa. Si un usuario no ve sus servicios, lo primero que hay que mirar son sus permisos en Kubernetes. Adoptar un namespace existente como proyecto solo le añade una etiqueta: no mueve Deployments, Services ni datos.
El backend está escrito en Rust, la licencia es Apache-2.0 y las versiones se publican firmadas con Sigstore y con atestación de procedencia de la build.
Cómo se instala
Hay tres caminos, según para quién sea:
- Un servidor Linux para un equipo: un instalador con interfaz web monta K3s o RKE2, Zeabur Identity (el proveedor de inicio de sesión con passkeys) y Zeabur. Pide 4 GiB de memoria como mínimo.
- Un clúster existente: un chart de Helm, con Kubernetes 1.30 o superior, un Ingress con TLS y Zeabur Identity ya funcionando.
- Uso personal:
zeaburctl uiabre la interfaz en tu ordenador contra el contexto actual de tu kubeconfig, en un puerto aleatorio de loopback.
En un clúster existente, tras registrar el cliente en Zeabur Identity y guardar su secreto en el namespace zeabur, la instalación es esta (según la documentación oficial):
helm install zeabur oci://ghcr.io/zeabur-oss/charts/zeabur \
--version <version> \
--namespace zeabur \
--set clusterName=production \
--set publicUrl=https://zeabur.example.com \
--set issuer.url=https://identity.example.com \
--set issuer.clientSecret.existingSecret=zeabur-oidc \
--set ingress.enabled=true \
--set ingress.className=traefik \
--set ingress.tls.secretName=zeabur-tls
kubectl -n zeabur rollout status deployment/zeaburEl chart crea los ClusterRoles de los miembros de proyecto y una ValidatingAdmissionPolicy que limita qué campos del Namespace pueden cambiar los desarrolladores, pero no asigna esos roles a nadie: lo hace un administrador desde la página de miembros.
Un aviso sobre la instalación en un único servidor: el instalador se ejecuta como root y la documentación lo lanza con un comando ssh que descarga la última versión y solo comprueba su SHA-256. Para verificar también la firma y la procedencia hay un procedimiento aparte con cosign y gh attestation verify. En un servidor que importe, merece la pena hacerlo.
Lo que me convence y lo que no
Me convence el enfoque. Una capa que no tiene estado propio ni CRD se puede quitar sin migrar nada, y la documentación dedica una sección a cómo dejar de usar Zeabur. Que cada acción vaya con el token del usuario hace que el control de acceso siga siendo el RBAC de Kubernetes, no uno paralelo. Y que el instalador y las imágenes se fijen por versión y digest dice mucho del cuidado del proyecto.
Lo que no: el propio README lo declara pre-alpha, avisa de que la API aún puede cambiar, de que se ha probado en pocos clústeres y de que no lo apuntes a uno que no te puedas permitir romper. Tiene 43 issues abiertos. Y el modo personal, que es el más fácil de probar, no tiene usuarios ni permisos: quien tenga el kubeconfig controla todo el clúster, y KubeSolo no aplica network policies, así que no hay aislamiento entre proyectos.
Zeabur frente a Coolify
Coolify es la PaaS autoalojada de referencia: más de 65.000 estrellas desde 2021 y la misma licencia Apache-2.0. Resuelven el mismo problema desde lados opuestos.
| Zeabur | Coolify | |
|---|---|---|
| Enfoque | Capa sobre Kubernetes, objetos estándar, sin estado propio | Plataforma completa sobre servidores con Docker, gestionados por SSH |
| Despliegue | Instalador (K3s, RKE2, KubeSolo), chart de Helm o zeaburctl ui local | curl | bash en un servidor; recomienda uno para Coolify y otros para las apps |
| Permisos | RBAC de Kubernetes con el token de cada usuario | Control de acceso por equipos propio |
| Licencia | Apache-2.0 | Apache-2.0 |
| Madurez | Pre-alpha, 641 estrellas | Proyecto consolidado, más de 65.000 estrellas, más de 360 servicios de un clic |
Si no tienes Kubernetes y quieres desplegar apps y bases de datos en un par de VPS, Coolify es la opción sensata hoy: más madura y con muchos más servicios listos. Zeabur tiene sentido si ya operas Kubernetes y quieres dar a tus equipos una interfaz de PaaS sin meter otra fuente de verdad entre ellos y el clúster. Hoy, en un clúster de pruebas.
Fuentes
- zeabur-oss/zeabur, GitHub
- Install Zeabur in an existing cluster, Zeabur docs
- Personal use: install on a small machine, Zeabur docs
- Release files and verification, Zeabur docs
- coollabsio/coolify, GitHub