Deploy

Virtual from $14.99/mo · Bare metal from $24.00/mo

DeployClient Login

Software studio · Product engineering

Tombasoft

Per-branch environments that appear on push and disappear on merge, on a build fleet sized for the worst ten minutes of the day rather than the average.

Visit Tombasoft

Architecture published with the organisation’s permission.

The problem

  • Hard constraints
  • A review environment must be reachable within minutes of a push, not hours.
  • Builds must not be able to starve anything a human is currently looking at.
  • A failed deployment has to roll back without a person editing configuration under pressure.
  • Environment count moves with the branch count, so the cost of an idle environment has to be near zero.

Tombasoft ships several products with different release rhythms, and reviews happen against running software rather than screenshots. That means an environment per branch, created on demand, and it means deployments that do not wait for a weekly window.

Their previous arrangement was a single large machine doing everything: builds, review environments and staging on the same box. A heavy build made the review environments unusable, and a broken review environment could take staging with it.

Build times were also the wrong shape. Most of the pipeline parallelises across cores; two stages do not, and those two stages were setting the pace for everyone.

Architecture

  1. Edge

    Review environments

    4 ×Super VPS Launch

  2. Build

    Parallel build fleet

    1 ×Apex 4

  3. Build

    Single-thread runner

    1 ×Forge 2

  4. Application

    Staging and production

    2 ×Forge 4

A change moving from branch to production. The build fleet feeds artefacts forward; it never sits in the serving path.

What it runs on

  • Edge

    Review environments

    4 ×Super VPS Launch

    2 vCore · 4 GB · 40 GB NVME

    A pool of small virtual servers, one per open branch. They are cheap enough to be disposable, which is the property that makes per-branch environments work at all.

    From $14.99 per month

  • Build

    Parallel build fleet

    1 ×Apex 4

    AMD EPYC 4584PX · 128 GB · 2× 960 GB NVMe + 2× 1.92 TB NVMe

    Thirty-two threads at 4.2 GHz with 128 GB, because the compile and test matrix is embarrassingly parallel and the whole point is to finish the wide part of the pipeline fast — without giving up the clock the narrow part needs.

    From $375.00 per month, $374.00 one-time setup

  • Build

    Single-thread runner

    1 ×Forge 2

    Intel Core i7-7700K · 64 GB · 2× 450 GB NVMe

    The two stages that refuse to parallelise are pinned to a four-core part clocked at 4.2 GHz, with 64 GB behind it. Adding cores would have done nothing for them; adding megahertz did.

    From $75.00 per month, $75.00 one-time setup

  • Application

    Staging and production

    2 ×Forge 4

    Model varies — clock and cores guaranteed · 32 GB DDR4 · 2× 2 TB NVMe

    Two matched machines so a release can be cut over between them and rolled back by pointing at the other one. Identical hardware means staging actually predicts production.

    From $93.00 per month

Techniques worth naming

  1. Ephemeral per-branch environments

    Opening a branch provisions an environment from a base image; merging or deleting the branch destroys it. Nothing is hand-maintained, so nothing drifts, and a stale environment cannot quietly become the one everybody tests against.

  2. Immutable build artefacts

    The artefact promoted to production is byte-for-byte the artefact that passed review. Nothing is rebuilt at deploy time, which removes the entire category of "it worked in staging".

  3. Blue/green cutover

    A release is deployed to the idle machine, health-checked while still dark, and only then given traffic. Rollback is the same switch in reverse and takes as long as a DNS-free reload.

  4. Workload-shaped hardware

    The pipeline was measured before anything was bought. Wide stages went to the many-core machine, narrow stages to the high-clock one. This is only possible when the CPU model is published before you order.

  5. NVMe-resident build cache

    Dependency and compiler caches live on local NVMe rather than a network mount. A cold build is rare; a warm one does not spend its time waiting on a filesystem.

  6. Root access as a requirement

    Toolchains, kernel parameters and container runtimes are all pinned by the team. A managed platform that decides these for you is not a smaller problem, it is a different one.

What changed

  • Review happens against a running environment on every branch, and the environment goes away by itself when the branch does.
  • Builds and human-facing environments no longer share a machine, so a heavy pipeline run is invisible to whoever is reviewing.
  • Deployments are ad hoc by design rather than by exception — the rollback path is the same mechanism as the deploy path, so shipping on a Friday is not a policy question.
  • Capacity is a decision they revisit deliberately, not one that upstream makes for them during a busy week.

No performance percentages appear on this page. We publish figures we have measured under a named method, and these deployments are described by their architecture instead.

Ready when you are

Bring us a workload, not a shopping list

Tell us what the thing actually does and we will tell you which machines fit — including when the answer is a cheaper one than you asked for.

Deploy in minutesor compare every plan

Virtual from $14.99/moBare metal from $24.00/mo