Deploy desde GitHub a tu propio servidor

1. 1Build. El código se compila en un contenedor temporal. Un repositorio con Dockerfile se compila con él. Sin Dockerfile, Railpack resuelve el build para Node, Python, Go, sitios estáticos y más, y Zelie muestra los comandos de build y de arranque que ha elegido.
2. 2Tests. Los tests del proyecto se ejecutan en la imagen nueva, en un contenedor propio, durante diez minutos como máximo. En proyectos Node, Zelie encuentra solo el script de tests; se puede indicar cualquier otro comando. Si un test falla, se mantiene la versión anterior.
3. 3Comprobación de estado. La versión nueva arranca junto a la anterior. Una app con dominio tiene que responder en su ruta de estado en menos de un minuto.
4. 4En vivo. El tráfico pasa a la nueva. El commit en GitHub se marca como compilando, en vivo o fallido.

Si falla algún paso, la versión anterior sigue sirviendo y el log muestra por qué. Se guardan las imágenes de las últimas cinco versiones en vivo, así que volver atrás lleva uno o dos segundos.

Al conectar GitHub se crea una GitHub App en tu propia cuenta u organización, con acceso solo a los repositorios que elijas. Los repositorios privados funcionan. La App puede leer código y marcar el estado de los commits, nada más, y su clave privada se cifra antes de guardarse.

• Cada push a la rama de la app la despliega, si lo dejas activado.
• Un push solo despliega las apps configuradas con ese repositorio y esa rama, así que una GitHub App sirve a muchas apps sin que se estorben entre sí.
• Cada webhook se comprueba con su secreto antes que nada, y una entrega que llega dos veces se procesa una sola vez.
• Los repositorios públicos se despliegan sin la App, cuando inicias tú el deploy.

Una imagen de contenedor

Cualquier imagen pública, como nginx:1.27, con su propio dominio y HTTPS. Zelie consulta el registro una vez al día y ofrece la imagen nueva cuando la etiqueta ha cambiado.

Tus propios archivos

Elige Node.js, Python, Bun, Deno o Java y sube los archivos, o envíalos por SFTP. Esto encaja con un bot de Discord o un sitio pequeño. Aquí no hay paso de build: los archivos son la app.

Un dominio y HTTPS

Instalado con un dominio, Zelie obtiene certificados de Let’s Encrypt. Detrás de un Cloudflare Tunnel, Cloudflare se encarga del HTTPS y no queda ningún puerto abierto en el servidor.

Variables y secretos

Normales y secretas, o un archivo .env completo pegado de una vez. Un secreto se sella al guardarse, y los builds reciben las variables como secretos de BuildKit, que no quedan en la imagen.

Bases de datos al lado

PostgreSQL, MariaDB o Redis con un clic. Al vincular una, la app recibe DATABASE_URL o REDIS_URL, y nada más puede llegar a ella.

Logs y métricas en vivo

Logs de build, de deploy y de la app en el momento. Peticiones, errores del servidor, memoria, CPU y tráfico, una lectura por minuto, guardadas durante un día.

Cierres controlados

Una app que se detiene sola vuelve a arrancar, esperando más tras cada cierre. Tras cinco cierres en diez minutos se queda detenida y el panel dice por qué.

Su propio contenedor

Su propia red y su propio user namespace, con límites de memoria y CPU. Root dentro del contenedor no es nadie en el servidor.

Zelie es un binario, una descarga de unos 50 MB, con su propio containerd y su estado en SQLite. Sus propios procesos se quedan por debajo de 66 MB de memoria en reposo, así que un VPS pequeño tiene sitio para las apps. Funciona en Debian o Ubuntu, amd64 o arm64, y el mismo panel puede ejecutar servidores de juegos junto a tus apps. En qué se diferencia de Coolify está en la comparación.

Para hacer deploy en cada push, GitHub tiene que llegar al panel, cosa que puede hacer con un dominio o un Cloudflare Tunnel. Cada app es una imagen, un Dockerfile o una carpeta de archivos; los archivos de Docker Compose no se leen.