Running the Build Server

The build server that powers automated releases ships with the product itself — there is nothing extra to install or license.

Starting It

cd docker
cp build.env.example build.env
docker compose --profile build up -d build-agent build-dind
./build/bootstrap-sandbox-image.sh

The bootstrap script builds the sandbox image and loads it into the isolated build daemon — run it once after starting the containers, and again any time the sandbox image changes.

Configuring Keys

Set two keys in docker/build.env:

RELEASE_RUNNER_KEY
RELEASE_RUNNER_CALLBACK_KEY

Both must exactly match the app's own RELEASE_RUNNER_* environment variables. The build agent loads only this file — it never sees your application's database, cache, or license signing credentials, only these two keys.

Two Containers, Two Networks

build-agent — receives signed build requests from the app and drives the isolated Docker daemon. It sits on both the app's network and the build network.
build-dind — an isolated Docker-in-Docker daemon where every sandbox actually runs. It never joins the application's network and publishes no ports.

Running on a Separate Host

The build server does not have to share a machine with the rest of the platform. Deploy the same docker/ compose on a separate host with only the build profile enabled, then point the app's RELEASE_RUNNER_URL at that host — no code changes required.

Running the Build Server