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.
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
Edge
Review environments
4 ×Volt 1
Build
Parallel build fleet
1 ×Apex 5
Build
Single-thread runner
1 ×Forge 9
Application
Staging and production
2 ×Forge 4
What it runs on
Edge
Review environments
4 ×Volt 1
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 $6.99 per month
Build
Parallel build fleet
1 ×Apex 5
AMD EPYC 7371 · 128 GB DDR4 · 2× 960 GB NVMe
Thirty-two threads at 3.8 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 — on a clock that is still respectable when a stage refuses to spread.
From $239.99 per month, $149.00 one-time setup
Build
Single-thread runner
1 ×Forge 9
Ryzen 7 3800X · 32 GB DDR4 · 2× 480 GB NVMe + 1× 14 TB SATA
The two stages that refuse to parallelise are pinned to an eight-core part that turbos to 4.5 GHz, with 32 GB behind it. Adding cores would have done nothing for them; adding megahertz did.
From $120.99 per month
Application
Staging and production
2 ×Forge 4
i7-8700K · 32 GB DDR4 · 2× 480 GB SSD
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 $109.99 per month
Techniques worth naming
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.
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".
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.
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.
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.
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.
Virtual from $6.99/moBare metal from $35.99/mo