Builds

A service is built in one of two ways.

• Buildpack. Clusterz reads your code and builds it without a Dockerfile. build_command is the npm scripts to run, like npm run build, and start_command starts the service.
• Dockerfile. Clusterz builds the Dockerfile you name. dockerfile is its path from root.

MonoreposCopy Anchor Link

A service lives in a folder, root, and the build reads that folder only. Both build methods honour it, so api/ and web/ of one repository are built separately, as two services of one app.

What Clusterz findsCopy Anchor Link

With no clusterz.yaml, Clusterz reads the repository in this order:

1. A docker-compose.yml or compose.yaml. Each service with a build becomes a service, and a Postgres or Redis service becomes the app's database instead of a container.
2. A Procfile. web is the service, release is the release command, and every other process is a worker.
3. npm, yarn and pnpm workspaces, Turborepo and Nx.
4. A folder with its own Dockerfile, package.json, go.mod, pyproject.toml, requirements.txt, Gemfile or composer.json.

From the framework it takes the start command, the port and the release command. Prisma, Django, Alembic, Rails and Laravel migrations are recognised.

Build-time variablesCopy Anchor Link

A variable marked at_build reaches the build as well as the running service: buildpacks read it as an environment variable, and a Dockerfile as an ARG it declares. Use it for values built into the app, like NEXT_PUBLIC_SITE_URL. The build log masks a value of four characters or more.

cluz env set NEXT_PUBLIC_SITE_URL=https://shop.example.com --build

Change a setting without the fileCopy Anchor Link

cluz projects update --root api --dockerfile api/Dockerfile --release-command "npm run migrate"

This changes the folder, the Dockerfile and the commands of an app that exists. Pass an empty value to clear a command, and --auto-deploy=false to stop pushes from deploying.