Your promotion tool decides what moves. Nimbus proves what was validated. Those are two different questions, and they are better answered by two tools that stay in their lane than by one tool with a view on everything. If you already run a deployment suite, keep it — Nimbus adds proof around the deploy rather than opinions about the pipeline that built it.
Two layers, two questions
A Salesforce delivery setup has a promotion layer and an evidence layer. Most teams have a mature promotion layer and an implicit evidence layer — “the pipeline was green, so it must have been fine.”
- Promotion layer — “what moves next, and in what order?” Branch and environment models, org comparison, dependency-aware metadata selection, backups and rollback tooling, work-item and approval workflow, audit UIs for non-developers. This is what the established suites do, at org scale, and they are good at it.
- Evidence layer — “what exactly was proven, against which bytes, in which org, by whom, and is that still true right now?” Gates that run before anything is promoted, a real Salesforce validation of the identical payload, and a durable record of both that can be checked later without trusting the tool that produced it. This is Nimbus.
The layers don't overlap much, which is why the comparison here is a division of labour rather than a scorecard. Nimbus has no pipeline model, no org-comparison engine, no backup product, and no work-item tracker — deliberately, not as a roadmap gap.
What Nimbus adds
Gates that run before an org is involved
Nimbus runs your Apex test suite locally in seconds — no org, no deploy, no queue. A typical test completes in tens of milliseconds, and suites of thousands of tests finish in seconds. That makes it practical to gate on the full suite, on line and branch coverage, and on mutation testing before a change is ever offered to the promotion pipeline — so the pipeline spends its org time on changes that already cleared the cheap checks.
Validation of the exact payload
nimbus deploy snapshots the selected source into a content-addressed bundle, runs the local gates against that bundle, validates the identical bytes in the target org with a real Salesforce check-only validation, and only then deploys. The thing that was tested and the thing that ships are the same bytes, by construction — not by convention. Details on the deploy page.
Receipts as portable evidence
nimbus release validate writes an immutable receipt: bundle digest, git revision, target-org fingerprint, gate results, Salesforce validation job ID, and its quick-deploy expiry. nimbus release deploy verifies the receipt still matches — same org, same bytes, unexpired validation, compatible toolchain — and refuses to deploy on any drift. Receipts and bundles are ordinary CI artifacts: validate on one runner, hold for human approval, deploy the exact validated payload from another machine. The release workflow page covers the full shape.
Deploy-queue diagnosis
nimbus release status, watch, and requeue give visibility into deploy-queue state and recover jobs stuck in Pending — the part of a Salesforce deployment that is usually opaque regardless of which tool submitted it.
What the suites add
- Pipeline orchestration. Environment topologies, branch strategies, promotion sequencing across many orgs, scheduling — the machinery that decides what moves and when.
- Org comparison and rollback tooling at org scale. Diffing full org metadata, selective deploys from a comparison, backups and restore. Nimbus has none of this.
- Work-item and compliance workflow. Ticket linkage, approvals, and audit views built for release managers and admins, not only for developers on a command line.
- Coverage of non-Apex change. Suites handle the whole metadata and configuration surface as a promotion problem, including work done entirely by admins.
If you're choosing a promotion tool, this page has no opinion on which one. Nimbus sits underneath whichever you pick.
How they fit together
The common shape: Nimbus gates and proves, the suite promotes.
- Development:
nimbus testin the inner loop — no org needed. - Pull request: Nimbus runs the full suite plus coverage as the merge gate, emitting JUnit and Cobertura XML for whatever CI you already run. See the CI setup page.
- Before promotion:
nimbus release validateagainst the target org produces the receipt — the evidence the approval decision is made on. - Promotion: your deployment suite moves the change through its pipeline, with the receipt attached as the proof of what was validated.
# Gate locally — seconds, no org
nimbus test "*" --coverage
# Validate the exact payload in the target org; write the receipt
nimbus release validate --release-profile ci --min-coverage 85
# Later, after approval — deploy exactly what was validated
nimbus release deploy --receipt .nimbus/releases/rel_*.jsonNothing here asks your pipeline to change shape. Point nimbus release at the bundle your pipeline assembles and the evidence layer slots in beneath it.
When Nimbus is not what you need
If the problem you're solving is “we have no promotion process,” Nimbus is not the answer — a deployment suite or a CI pipeline is, and Nimbus becomes useful once that exists. If the problem is “we promote confidently but can't say precisely what was proven about a given deployment, or re-check it afterwards,” that's the gap this layer fills.
Add the evidence layer to the pipeline you already run
nimbus deploy — local gates, Salesforce validation, and a local receipt in one command — is free, and it changes nothing about how your promotion tool works. The fastest way to evaluate it is to run it against a change you were going to promote anyway and read the receipt.