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.
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. 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 for examples.