Build Plan (Dockerfile & zbpack)

Git services are built on Zenavo's build machines with BuildKit. How a service is built is its build plan, which you can preview before deploying.

Dockerfile

If the service's root directory contains a Dockerfile, it is used as is. Set a different path under Advanced Settings → Dockerfile path when adding the service, or later on the service's Settings tab → Dockerfile (for example deploy/api.Dockerfile, relative to the root directory).

zbpack

Without a Dockerfile, zbpack detects the language and framework and generates one. It supports Node.js, Bun, Deno, Python, Go, PHP, Ruby, Java, Rust, .NET, static sites and more. zbpack is also used when the repository has a zbpack.json file, or the service has ZBPACK_* environment variables, which configure zbpack (for example its build and start commands).

zbpack-built images listen on port 8080, so that is the service's HTTP port unless you set another.

zbpack options

On the service's Settings tab → Build → zbpack options, enter one KEY=value per line:

• Keys starting with ZBPACK_, such as ZBPACK_BUILD_COMMAND=npm run build or ZBPACK_START_COMMAND=node dist/server.js, are passed to zbpack as variables. They take precedence over ZBPACK_* variables on the Variables tab.
• Other keys are written to zbpack.<service>.json in the root directory, the same as a zbpack.json file in the repository. A value written as JSON ({…}, […], true or false) keeps its type.

Setting any zbpack option builds the service with zbpack, even when the root directory has a Dockerfile.

Build arguments

On the Settings tab → Build → Build arguments, enter one KEY=value per line. Each is passed to the Dockerfile as an ARG (for generated Dockerfiles too). Reference a service variable with ${KEY} so a secret stays on the Variables tab; values are hidden in build logs.

Root directory

For monorepos, set Root Directory to the service's folder, such as /apps/api, when adding the service or later on the Settings tab. The build uses that folder as its context, for Dockerfiles and zbpack alike. It must be inside the repository.

To redeploy only when that folder changes, set the service's watch paths.

In the manifest

The Settings tab saves these fields of the service's source in the project manifest; you can also set them in an exported or imported manifest:

"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

The preview clones the branch and reports what the build will use, without building or running anything:

Row	Example
Provider	Dockerfile, go, nodejs, python…
Versions	Go Version 1.26.1, Node.js Version 22
Port	From the Dockerfile's EXPOSE, or 8080 for zbpack

Limits

Builds share Zenavo's build machines and are queued when they are busy. Cloning may take up to 10 minutes and the build itself up to 30 minutes. See Pricing for build minutes and machine sizes per plan.