NOME Build Cloud

NOME Build Cloud is a private AI build cloud: continuous integration and deployment that runs on hosts you own and control. You bring your own GitHub or GitLab project and your own pipeline YAML, point it at runners on your machines or the NOME cloud, and NOME handles BuildKit cache acceleration, AI pull-request review, test sharding, image signing, provenance, and deploy gates. There is no lock-in — the YAML stays portable and the runners are yours.

The in-app surface for this is Pipelines, where every run shows the provider, host, auth lane, and cost. The pages below are the technical reference. Start with Overview, then Architecture.

NOME Build Cloud connects to GitHub or GitLab. You authorize a connector, NOME ingests webhook events (push, pull/merge request, workflow runs), and runs dispatch to your chosen host. Commit and merge-request statuses are posted back so the verdict shows up where your team already looks. See GitHub and GitLab.

An owner-edge runner is a machine you own — a Mac, a Linux box, a home server, or a VM you created — registered as a NOME build host. You install the runner, pair it, and jobs execute there with your toolchain and your network. NOME-managed cloud runners are available when you would rather not operate a machine. See Owner-edge runner.

Cold builds are slow because every layer rebuilds. NOME Build Cloud keeps a warm BuildKit cache per project, isolated per project, so incremental builds reuse unchanged layers and only the changed work runs. Cache is content-addressed and never shared across projects or tenants. See BuildKit cache.

NOME Review reads the diff for each pull or merge request and posts structured findings — correctness risks, security issues, and reuse/simplification cleanups — with one-click apply where the patch stays on-diff. It runs through the same canonical reasoning path as the rest of NOME and never silently falls back. Review is one signal in the deploy gate, not a blocker you can't see. See the review stage and CodeRabbit compatibility.

Large suites are sharded across runners so wall-clock time drops, and flaky or failed tests get smart reruns instead of re-running the whole matrix. Results roll up into a single verdict per commit. See the test stage.

Build artifacts are signed, shipped with an SBOM (software bill of materials), and carry build provenance so you can verify what ran and where. Unsigned or unverifiable artifacts fail closed at the deploy gate. See Artifact signing.

A deploy gate is the set of conditions a change must satisfy before it ships: tests green, review signals resolved, artifacts signed, and a human approval where promotion is risky. Every deploy carries a rollback plan, and production traffic shifts are manual by default. See deploy gates.

Already use CodeRabbit? Keep it. NOME Build Cloud reads CodeRabbit's review status and uses it as one signal in the deploy gate — you do not need CodeRabbit to use NOME Build Cloud, and NOME Review goes beyond review into build, test, sign, deploy, and rollback. The exact support matrix is on the dedicated page: CodeRabbit.

Workloads that need a GPU or other accelerator run on dedicated lanes — model builds, CUDA compiles, inference smoke tests. Accelerator lanes use the same run contract, receipts, and cost tracking as CPU lanes. See accelerator lanes.

Runners are protected, customer jobs are ephemeral, cache and secrets are isolated per project, artifacts are signed, and every action emits an audit receipt. Branch protection and deploy approvals are enforced at the gate. Full model: Security and Secrets.

You control spend with concurrency caps, cache reuse, runner selection (your own hardware costs you nothing in NOME credits), and per-project budgets. Owner-edge runs that execute on your machines consume no NOME compute credits. See Cost controls.

Common issues — runner offline, cache miss, signature verification failed, a gate that blocked a deploy, a webhook that didn't arrive, CodeRabbit status not detected — are collected on the dedicated page: Troubleshooting.