Builds: settings, cache, queue and supply chain

Every app and function has its own build settings. Anything left empty is detected from the project. Changes apply from the next build; a build already running finishes with the settings it started with.

cloudhost apps build-config shop
cloudhost apps build-config set shop root-dir apps/web
cloudhost apps build-config set shop node-version 24
cloudhost apps build-config set shop ignore-command "git diff --quiet HEAD^ HEAD -- apps/web"
cloudhost apps build-config clear shop build-command

After each successful build, the installed dependencies and the framework's build cache (for example the Next.js cache) are saved for that project. The next build with the same key restores them, so the install and the build are faster. The key is made from the lock file (package-lock.json, pnpm-lock.yaml or yarn.lock), the Node.js version, the root folder and the framework.

• A change to the lock file, the Node.js version or the root folder makes a new key; the old cache is no longer used and goes in time.
• A project without a lock file is not cached.
• Each project's cache size: Hobby 500 MB, Pro 1 GB, Enterprise 2 GB. When it is full, the oldest entries go first.
• To build once without the cache, redeploy without cache; to remove everything, clear the cache.

cloudhost apps build-cache shop
cloudhost apps build-cache clear shop
cloudhost apps builds redeploy shop 83548b3f --no-cache

Each team runs as many builds at once as its plan allows: Hobby 1, Pro 3, Enterprise by contract. More builds wait in the team's queue and run in order, oldest first. The builds list shows each queued build's place and why it waits: the team is at its concurrent builds, or it is waiting for a free build machine.

A queued or running build can be cancelled; a running build stops and deploys nothing. A redeploy builds the same source or commit again, with today's settings.

cloudhost apps builds shop
cloudhost apps builds cancel shop 83548b3f
cloudhost apps builds redeploy shop 83548b3f

Each build's source is scanned, in the same isolated environment and before it is built, for keys, tokens and passwords committed by mistake. A finding only says where it is (file and line) and how likely it is a real secret (high or low); the value itself is never stored or shown.

With the block policy (default), a high finding stops the build. Remove the secret from the source, revoke and replace it, and keep it as a sensitive environment variable. With warn the build goes on and the findings show on the deployment page.

cloudhost apps builds secrets shop 83548b3f
cloudhost apps build-config set shop secret-scan warn

Every build with a lock file gets a bill of materials (SBOM) in the standard CycloneDX 1.5 format: every npm package with its version. Download it for licence review, security questionnaires or your own tools.

cloudhost apps builds sbom shop 83548b3f --output shop.cdx.json

Every build that deploys has a signed provenance record: what was built (the output's hash and version), from what (commit or source hash, lock file, SBOM hash), when, and on which build machine. It is signed with the platform's Ed25519 key; the signed bytes are CH-PROVENANCE-V1, a newline, then the statement as canonical JSON (keys sorted), so it can be checked outside the platform with the public key (GET /v1/provenance/key).

Verifying says whether the signature is valid, and whether it is the record the platform holds for that build.

cloudhost apps builds provenance shop 83548b3f
cloudhost apps builds provenance shop 83548b3f --verify

When a build fails, the platform reads its log and explains above it what happened, why, and how to fix it; when the error points to a file and line, it shows them. The CLI prints the same explanation when it follows a build.