# Build plans, Railpack and clearer build failures

Every deployment records how it was built, Railpack joins the supported builders, and build failures come with a reason and a next step.

Canonical URL: https://unbroker.cloud/changelog/2026-10-26-build-plans-and-railpack
Published: 2026-10-26
Tags: Apps

## Related reading

- [Cloud Apps](https://unbroker.cloud/deploy)
- [Deploy from Git](https://docs.unbroker.cloud/guides/deploy-from-git)

Before a build starts, Unbroker now checks the repository and writes down a **build plan**: the builder, the Dockerfile and context, the package manager and workspace, public build arguments, the secrets the build needs (by name, never the value) and the builder version. The plan is saved with the deployment and shown in its details, so you can see exactly how a version was built.

Problems such as a Dockerfile path that does not exist are caught before the build takes a builder slot.

#### Railpack

Add a `railpack.json` to the repository and the service builds with [Railpack](https://railpack.com). The builder is picked in a fixed order: a configured Dockerfile first, then `railpack.json`, then Unbroker's generated build, then Nixpacks.

#### Builds that explain their failures

A failed build is classified with a stable reason, whether it needs a change on your side, whether retrying can help, and a hint. Values that look like credentials are removed from the log. Cancelling a deployment now stops the clone, build or push in progress.

#### Secrets in Dockerfiles

A Dockerfile can mount any service variable by its name, such as `GITHUB_TOKEN`, with `RUN --mount=type=secret`. Only the secrets the Dockerfile asks for are passed in, and they never appear in build arguments, logs or the image. Generated JavaScript builds accept `GITHUB_TOKEN` as well as `NODE_AUTH_TOKEN` for private packages. Workers can now build from a Dockerfile too.

See [Private package registries](https://docs.unbroker.cloud/deployments/environment-variables#private-package-registries) for examples.