The same tool that runs your tests in milliseconds now ships them. nimbus deploy runs your local gates, validates the identical payload in Salesforce, then deploys it — one command. nimbus release splits validate from deploy with an immutable receipt, so what reaches production is byte-for-byte what passed.
A standard Salesforce deploy validates whatever is in your worktree at the moment you press enter. The tests that passed ten minutes ago ran against a different revision. The validation that succeeded yesterday belonged to a different payload. Nothing connects the evidence to the deployment.
nimbus deploy connects them. It snapshots the selected source into a content-addressed bundle first, and every subsequent stage — local validation, tests, coverage, the org's own check-only validation, the deploy itself — operates on that same bundle. The result is recorded in a receipt under .nimbus/releases/.
The ungated path stays available and stays explicit: nimbus sf project deploy start is the raw Salesforce deploy, spelled the way Salesforce spells it. Nimbus adds no shorter ungated alias — the shortest command is the safe one.
# One command: gates, org validation, deploy
nimbus deploy --target-org staging --source-dir force-app
# Production needs explicit confirmation
nimbus deploy --target-org production \
--manifest manifest/package.xml \
--confirm-production
# Deploy selected metadata only
nimbus deploy --target-org qa \
--metadata ApexClass:AccountService \
--metadata ApexClass:AccountServiceTest
# The intentionally ungated escape hatch —
# the raw Salesforce deploy, clearly spelled
nimbus sf project deploy start \
--target-org dev --source-dir force-appEvery stage reads the same staged bundle. A failure at any stage stops the run with a distinct exit code — 21 local gate, 22 Salesforce validation, 23 deploy — so CI can react precisely.
The selected source is materialized into a content-addressed bundle. Every later gate reads this exact payload — not a moving worktree.
nimbus validate compiles the bundled Apex and metadata against the same rules a check-only deploy enforces.
Your configured test selection, coverage threshold, mutation threshold, and permission-seam policy — run locally, in seconds.
A real check-only validation of the same bytes in the target org. For production targets, the validated job is retained for quick deploy.
Only after everything above passes. Production targets require explicit confirmation. Every step lands in the receipt.
Real release processes put a human decision between validation and deployment. nimbus release validate runs every gate plus a real Salesforce check-only validation and writes an immutable receipt: bundle digest, git revision, org fingerprint, gate results, the Salesforce validation job ID, and its exact quick-deploy expiry.
nimbus release deploy ships that receipt — and nothing else. Where Salesforce supports it, it reuses the validated org-side job via quick deploy, inside Salesforce's 10-day window, without retransmitting source. Otherwise it deploys the exact stored bundle. A receipt whose source changed, whose validation expired, or whose target org doesn't match is rejected. There is no override flag.
Receipts and bundles are portable artifacts: validate on one CI runner, hold for approval, deploy from another machine. That's the designed path, not a workaround.
# CI job 1: gates + Salesforce validation → receipt
nimbus release validate --release-profile production
# (approval happens here — a human, or your
# platform's protected-environment gate)
# CI job 2: deploy exactly the validated payload
nimbus release deploy \
--receipt .nimbus/releases/rel_01J9.json \
--release-profile production \
--confirm-production
# The org's deploy queue, from your terminal
nimbus release status # stuck-Pending diagnosis
nimbus release watch rel_01J9 # live progress
nimbus release requeue rel_01J9 # resubmit validated bundlenimbus sf passes any command — core or plugin, current or future — through to Salesforce CLI unchanged. Arguments, working directory, interactive prompts, signals, and exit codes are preserved. Nimbus does not parse or reinterpret this surface, so nothing Salesforce ships is ever missing or behind.
nimbus toolchain sf manages the dependency itself: report which sf the machine resolves, install the official @salesforce/cli package, and pin an exact version in committed config so every CI runner provably reproduces the same toolchain.
One tool starts every Salesforce task. The local loop where Nimbus is fastest, the remote surface where Salesforce is authoritative — with the seam made explicit, not hidden.
# Any sf command, unchanged
nimbus sf org login web
nimbus sf data query --query "SELECT Id FROM Account" \
--target-org dev
nimbus sf package version create --package core \
--code-coverage
# Toolchain: inspect and pin the Salesforce CLI
nimbus toolchain sf status --verbose
nimbus toolchain sf install --version 2.143.6
# Or from the other side: Nimbus as an sf plugin
sf plugins install @nimbus-solution/nimbus-sf-plugin
sf nimbus apex run testReady-to-copy release templates exist for GitHub Actions, GitLab CI/CD, Azure DevOps, and generic shell. Each runs validate in one job, carries the receipt and bundle as a pipeline artifact through your platform's environment approval, and deploys from a fresh runner — the receipt's own verification is the safety net for the hand-off.
Both editors ship a Releases view driven by the same engine: validate and deploy actions, a live stage timeline, release history recovered from disk after an IDE restart, and a production confirmation dialog showing the target org, source selection, destructive component count, receipt age, and bundle digest before the button enables. The only deploy button is the assured one.
See the release-in-CI reference for profiles, secrets, and the exit-code contract, and the VS Code page for the editor experience.
# GitHub Actions, condensed — full template in the repo
validate:
steps:
- run: nimbus toolchain sf install --version ${{ vars.SF_VERSION }}
- run: nimbus release validate --release-profile ci
- uses: actions/upload-artifact@v4
with: { name: release, path: .nimbus/releases/ }
deploy:
needs: validate
environment: production # ← your human approval gate
steps:
- uses: actions/download-artifact@v4
with: { name: release, path: .nimbus/releases/ }
- run: |
nimbus release deploy \
--receipt "$(ls .nimbus/releases/rel_*.json)" \
--release-profile ci --confirm-productionGated nimbus deploy is a Free command. If safety cost money while the ungated path was free, we would be pricing you onto the unsafe path.
Destructive changes, --ignore-errors, and production targets keep every confirmation Salesforce itself enforces. Nimbus adds gates; it never removes them.
Changed source, an expired validation, the wrong org, an incompatible toolchain — the deploy is rejected and you revalidate. There is deliberately no --force.
Everything on this page is optional. nimbus test, validate, and debug work with no Salesforce CLI, no network, and no org — exactly as before.
Yes. nimbus deploy is a one-shot gated deployment: it snapshots your source into a content-addressed bundle, runs Nimbus validation and your configured local test gates against that bundle, validates the same bytes in the target org with a real Salesforce check-only validation, and only then deploys. nimbus release splits validation from deployment with an immutable receipt for approval workflows.
No — it orchestrates above it. Salesforce CLI remains the platform adapter for auth, deploys, packaging, and data. nimbus sf passes any current or future sf command through unchanged — arguments, interactive prompts, and exit codes preserved — so you can start every Salesforce task with nimbus without losing anything sf can do.
No. Nimbus is the evidence layer: it snapshots what a deploy contains, runs your gates, validates it in the org, and attests the result in a signed receipt. It does not manage package versions, dependency-ordered installs, scratch-org pools, or data seeding — that stays with the package and promotion tooling you already use. Point nimbus release at the bundle your pipeline assembles and it adds the proof around the deploy, rather than replacing the pipeline that builds it. Nimbus proves; your build and promotion tools ship.
An immutable JSON record written by nimbus release validate: the exact 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 portable CI artifacts: validate on one machine, approve, deploy from another.
When nimbus release validate runs a production-style check-only validation, Salesforce keeps the validated job quick-deployable for 10 days. The receipt records the job ID and the exact expiry, and nimbus release deploy uses sf project deploy quick — deploying the already-validated job without retransmitting source. If quick deploy is unavailable and policy permits, Nimbus deploys the exact stored bundle instead — never a freshly read checkout.
No. nimbus deploy — local gates plus Salesforce validation plus a local receipt — is Free, and so is nimbus sf pass-through. Pro adds the release workflow around it: named release profiles, portable validate-approve-deploy receipts, release history, CI use, and the VS Code and IntelliJ release views.
nimbus deploy is Free. Receipts, profiles, and CI release workflows are Pro — currently free, no card required.