Quox Dev Suite · QuoxBuild
One queue. Every build accounted for.
QuoxBuild is the queue that ends the race: builds serialised, duplicate requests folded into one run, and every build carrying who asked, from which stream, and whether the result actually runs. We built it for ourselves first, because we had to.
BuildsserialisedDuplicatescoalescedEvery buildattributedShips withdev-server registrationIn plain words
What it is, where it lives, when to reach for it
- What is it
- A build queue that runs on your own dev server and writes a receipt for every build.
- Where do I use it
- On a dev server you registered with Quox, dispatched from your terminal or the Dev Suite hub.
- When would I use it
- When two sessions can both trigger a build and you need one queue, not a race.
- How do I use it
- Run
quox build <target>for a target your host operator registered. It queues, runs, and verifies.
The problem
Agents build in parallel. Docker does not.
Agent-driven development multiplies builders. Two sessions finish work in the same minute; both rebuild the same service; the images race, the dist directory is written twice, and the container that comes up matches neither branch of the story. The failure is quiet, which makes it expensive.
We hit this hard enough that direct docker builds are banned by hook across our whole estate, and every build goes through a queue that serialises, dedupes and attributes. That queue has shipped every Quox release since. QuoxBuild is that queue, extracted into a product your dev servers get on registration.
The model
Four moves, stated before built. This page is the brief.
Put three agent sessions on one codebase and watch them race the same docker build into a corrupted image.
The tags are honest per row: the queue, the verbs, the witnessed receipt chain and the registration-delivered kit were all driven live on a real dev server on 2026-08-16. What remains planned says so below.
Ships with the server
Registering a dev server installs the build daemon as a systemd service, the same way the rest of the kit arrives. No hand setup: the queue exists the moment the host does.
Serialise, coalesce, attribute
Parallel agent sessions request builds; the queue runs them one at a time, folds duplicate requests inside a short window into one run, and records who asked, from which stream, and why, on every build.
CLI-first, like everything
quox build <target>, quox build status, quox build history. A session queues a build in one line and reads the outcome without ever touching docker directly.
Green means verified
A build is not done when the compiler exits. The receipt chain runs compiled, then container alive, then endpoint answering, and the result lands on the evidence chain like every other governed action.
Honest state
What is real today, what is planned
- v1 driven end to end on a real dev server (2026-08-16): quox build dispatch through the governed chain, a pre-registered target built, deployed, health-probed, and its witnessed receipt written, green only after the service answered
- Coalescing proven live: two parallel dispatches became one build whose receipt names both requesters; a killed build reported FAIL with the failing step and exit code, never a hollow green
- The refusal is real: dispatching an unregistered target is rejected by the host with a 422 naming it, so the envelope can never carry a command
- The pattern also runs our own shipping every day: every Quox service build goes through the internal queue instance that inspired the product
- It learns from its own receipts: a target that fails repeatedly records the pattern, and the next dispatch of that target surfaces it BEFORE a human approves. Deliberately restrained, a single red build is a typo rather than a lesson, and no model runs anywhere in the build path
- Live log tail and a stop verb (the journal records every step host-side; the control plane cannot stream or cancel yet)
- HITL approval on protected targets
- Plugin manifest and bundle packaging polish
The pattern today
Every Quox build already runs through one queue
This is a real Terminal 9 session from the night this page was built: parallel sessions queue targets, the daemon serialises and stamps each with its stream and duration. The product wraps this pattern per dev server; the queue itself is live today.
- 15:45:43collectorfrom T4146s[DEVSUITE-SKILLS/ORG-GATE]"org-gate quoxplan tools + proxy to owning org"
- 15:54:27collectorfrom T4161s[DEVSUITE-SKILLS/F1-FLAT]"pack v4 flat skills (F1)"
- 15:57:35quoxflowfrom T4188s[DEVSUITE-SKILLS/F1-FLAT]"core-dev-pack seed v4"
How you get it
In the bundle, not yet on its own
In the Dev Suite
QuoxBuild ships as part of the Dev Suite bundle at $169, nine members against $212 bought separately, and it has its own store row at $19: the governed build queue, the receipts and the dashboard panel, on your own QuoxCORE instance. The platform itself is free during the public beta.
On its own
Or take just the queue: QuoxBuild has its own store row at $20. The pattern runs our own shipping every day, which is where the receipts above come from.
QuoxBuild
Roadmap in. Receipts out.
Part of the Quox Dev Suite. The queue that shipped Quox becomes the queue that ships your work.