Most hosting conversations start at the running container: memory, CPU, requests, uptime. The experience the customer actually feels starts earlier. It starts when they press deploy and wait.

A build that takes eleven minutes, fails on a transient dependency download and shows a scroll of unrelated output is not a neutral detail. It changes how often people deploy, how confident they are in a change, and how quickly they can recover from a bad release.

Three properties of a good build

  1. Deterministic. The same commit and lockfile produce the same output. No “works on the second try” unless a dependency registry actually failed.
  2. Observable. The log says which step is running, what it installed and where it failed. The customer should not need SSH to understand a failed build.
  3. Bounded. A build has a timeout, a memory ceiling and a queue position. A stuck build must not hold the fleet forever.

Cache the expensive parts

Dependencies are usually the slowest part of a cold build. Caching the package manager, compiler output or Docker layers between releases turns a five-minute install into seconds. It also reduces the chance of a registry hiccup breaking a deploy.

# a useful build log distinguishes these phases
1. clone        repository + branch
2. install      lockfile-resolved dependencies
3. compile      application build
4. package      runtime image
5. start        process + health check

When a build fails, the phase tells the customer where to look. “Build failed” does not.

Build limits are a fairness mechanism

Builds consume shared CPU and a finite number of build slots. A monthly build allowance is not a punishment; it keeps one project from starving every other project on the node. Failed and cancelled releases should not consume the allowance.

What we changed

We made the build step visible in the app console, kept the raw log next to the parsed summary, and made a failed release a first-class state instead of a silent retry. We also separated the build queue from the lifecycle queue so a stuck build does not block a stop or a restart.

Measure the wait, not just the uptime. A platform can be “up” and still be painful to use if every release takes long enough to discourage releasing.

The build is the first thing a customer sees after “deploy”. It deserves the same care as the running app.

Builds Developer experience Reliability