Build Studio: private container builds for app.nz

Build Studio exists for the deploys that are not static: server apps, custom runtimes, workers, and anything that needs a container image. The core contract is simple: app.nz takes a build context and Dockerfile, builds an image, pushes it to the private registry, and records the result.

The details are where reliability lives.

Inline context, explicit Dockerfile

The API accepts a Dockerfile and optional build context. The server writes the Dockerfile into a temporary directory as Dockerfile.appnz, arranges the context, and runs docker build from that directory. If a project needs special build behavior, the Dockerfile is the source of truth.

For static apps, app.nz can infer a simple Node build. For serious server apps, especially Rust, Go, Python with system packages, or GPU images, inference is the wrong abstraction. The Dockerfile is the reproducible build recipe.

Private registry naming

Successful builds push into the app.nz registry under a user namespace:

registry.app.nz/u-<user>/<image>:<tag>

That gives every image a stable release reference without exposing another user's namespace. The release system can later deploy by image ref instead of rebuilding source.

This is also the main reason "deploy" and "build" should be separate words. A build turns source into an image. A release points traffic at an image.

Temporary Docker auth

Build jobs need registry credentials, but the host should not have its normal Docker config mutated by every user build. app.nz writes Docker credentials into a temporary DOCKER_CONFIG directory for the duration of the build and deletes that directory afterward.

That avoids a subtle class of operational bugs:

• one build overwriting another credential,
• host-level auth leaking into user builds,
• future jobs inheriting stale registry state,
• local developer Docker config changing after a test run.

Credentials should be scoped to the job that needs them.

Logs are user-facing

Build logs are both operational data and product UI. Users need the error, but they should not see secrets echoed from build args, environment, or failed shell commands. app.nz runs logs through a redaction path before persistence.

That does not make it safe to print secrets in builds. It makes the common failure mode less damaging.

What makes container builds slow

Build Studio cannot make Docker ignore physics. Slow builds usually come from one of these:

• a giant context sent to the builder,
• dependency installation before copying lockfiles,
• missing layer cache,
• compiling native code every build,
• downloading toolchains in the runtime stage,
• pushing huge layers over the network.

The platform can help by surfacing build phase timings and encouraging cache-friendly Dockerfiles. It should not hide the fact that a bad Dockerfile is a slow build recipe.

The release path we want

The target shape is:

build once push image store immutable image ref release by moving routing metadata roll back by pointing to the previous ref

Once the image exists, releasing it should be a control-plane operation. That is how app.nz gets to fast server deploys without pretending source compilation is free.