Plan de compilación (Dockerfile y zbpack)

Los servicios Git se compilan en las máquinas de compilación de Zenavo con BuildKit. Cómo se compila un servicio es su plan de compilación, que puedes previsualizar antes de desplegar.

Dockerfile

Si el directorio raíz del servicio contiene un Dockerfile, se usa tal cual. Indica otra ruta en Advanced Settings → Dockerfile path al añadir el servicio, o más tarde en la pestaña Settings del servicio → Dockerfile (por ejemplo deploy/api.Dockerfile, relativa al directorio raíz).

zbpack

Sin Dockerfile, zbpack detecta el lenguaje y el framework y genera uno. Admite Node.js, Bun, Deno, Python, Go, PHP, Ruby, Java, Rust, .NET, sitios estáticos y más. zbpack también se usa cuando el repositorio tiene un archivo zbpack.json, o el servicio tiene variables de entorno ZBPACK_*, que configuran zbpack (por ejemplo, sus comandos de compilación y arranque).

Las imágenes compiladas con zbpack escuchan en el puerto 8080, así que ese es el puerto HTTP del servicio salvo que indiques otro.

zbpack options

En la pestaña Settings del servicio → Build → zbpack options, escribe un KEY=value por línea:

• Las claves que empiezan por ZBPACK_, como ZBPACK_BUILD_COMMAND=npm run build o ZBPACK_START_COMMAND=node dist/server.js, se pasan a zbpack como variables. Tienen prioridad sobre las variables ZBPACK_* de la pestaña Variables.
• Las demás claves se escriben en zbpack.<service>.json en el directorio raíz, igual que un archivo zbpack.json en el repositorio. Un valor escrito como JSON ({…}, […], true o false) conserva su tipo.

Definir cualquier opción de zbpack hace que el servicio se compile con zbpack, aunque el directorio raíz tenga un Dockerfile.

Argumentos de compilación

En la pestaña Settings → Build → Build arguments, escribe un KEY=value por línea. Cada uno se pasa a la compilación: tu propio Dockerfile lo lee con una línea ARG del mismo nombre, y en un Dockerfile que genera zbpack, Zenavo añade esa línea ARG en cada etapa que ejecuta un comando. Las variables de la pestaña Variables no se pasan solas a la compilación; para usar una, refiérela con ${KEY}, por ejemplo VITE_API_URL=${API_URL}.

Los valores se ocultan en los registros de compilación, pero un valor puede leerse del historial de la imagen compilada cuando la etapa que lo declara está en la imagen final, y de la salida si la compilación lo escribe allí. Pasa un secreto como argumento de compilación solo cuando la compilación lo necesite.

Directorio raíz

En monorepos, pon Root Directory en la carpeta del servicio, como /apps/api, al añadir el servicio o más tarde en la pestaña Settings. La compilación usa esa carpeta como contexto, tanto con Dockerfile como con zbpack. Debe estar dentro del repositorio.

Para volver a desplegar solo cuando cambie esa carpeta, define los watch paths del servicio.

En el manifiesto

La pestaña Settings guarda estos campos del source del servicio en el manifiesto del proyecto; también puedes definirlos en un manifiesto exportado o importado:

"source": {
  "git": "https://github.com/acme/mono",
  "ref": "main",
  "context": "apps/api",
  "dockerfile": "Dockerfile",
  "build_args": { "NODE_ENV": "production" },
  "zbpack": { "ZBPACK_BUILD_COMMAND": "npm run build" },
  "auto_deploy": true,
  "watch_paths": ["apps/api/", "packages/shared/"]
}

Build Plan Preview

La vista previa clona la rama e indica qué usará la compilación, sin compilar ni ejecutar nada:

Fila	Ejemplo
Provider	Dockerfile, go, nodejs, python…
Versions	Go Version 1.26.1, Node.js Version 22
Port	Del EXPOSE del Dockerfile, o 8080 con zbpack

Límites

Las compilaciones comparten las máquinas de compilación de Zenavo y se ponen en cola cuando están ocupadas. Una compilación, clonación incluida, puede durar tanto como la compilación más larga del plan: 15 minutos en Free, 30 en Dev y 60 en Pro, Team y Enterprise; la clonación sola está limitada a 10 minutos. Una compilación que llega al límite se detiene, el despliegue falla y sus minutos cuentan igualmente. Consulta Uso y facturación para los minutos de compilación por plan.