For Salesforce engineering teams

Nimbus gives Salesforce teams tests on every pull request, without a connected org.

Apex tests and Salesforce flows run on your developers' machines and on your CI runners, against an embedded database. New developers can run the full suite on their first day, and deploys are gated on the exact payload the tests passed against. No source or schema is sent to Nimbus.

Team plan from $99 per month for 5 seats. Enterprise setup as a fixed-fee, two-week engagement.

Pull request · checks
OK
nimbus test
No connected org. JUnit XML uploaded.
38 s
OK
Coverage · Cobertura
Line and branch, gated at the threshold you set.
2 s
OK
nimbus release validate
Check-only validation in Salesforce. Receipt written.
4 m 02 s
..
Awaiting approval
nimbus release deploy will ship exactly the validated payload.

Benchmarks

Four open-source Apex suites, 837 tests, run once against a Salesforce org (deploy, then test) and once on Nimbus. Every test passes in both. Measured 2026-08-17.

Every run behind these medians
1 m 46 sSalesforce org, deploy and test
2.3 sNimbus, same tests
47×Faster, end to end
SuiteTestsOrgNimbusFactor
apex-test-kitTest-data factory, DML across standard objects8726.6 s0.6 s45×
sobject-fabricatorIn-memory SObject fabrication, relationship trees12422.9 s0.5 s49×
trigger-actions-frameworkTrigger dispatch, custom metadata, order of execution15528.8 s0.5 s55×
fflib-apex-mocksMocking framework, stubs, matchers, verification47127.8 s0.7 s40×

Three problems this removes

The shared org
Several developers share one org.

A one-line trigger change means a push, a four-minute wait and then a failure caused by someone else's test data. Twenty minutes later you have debugged a problem that was not yours.

With NimbusEach test runs in its own transaction on the developer's machine. There is no shared state and no queue.
The onboarding tax
A new developer waits days for org access.

Day one: request org access. Day three: an admin provisions a sandbox. Day five: the first test run. Every new hire, on every project.

With NimbusThey clone the repo, install Nimbus and run the suite. Org access can come later, for deployment.
The CI tax
CI fails for reasons that have nothing to do with the code.

A JWT certificate, a connected org, a DevHub with scratch org limits, and an org pool that runs dry. The Java team next door has coverage badges that just work.

With Nimbusnimbus test runs in GitHub Actions or GitLab and writes JUnit XML and Cobertura into the dashboards you already have.

Where Nimbus sits in the pipeline

Your org stays the deployment target and the system of record. Nimbus handles the steps that never needed an org.

Pull request
Developer opens a PR

Source-driven. Apex, triggers, flows and metadata in git.

Nimbus, pre-merge
nimbus test

The full suite, Apex and flows, on the CI runner. No connected org, no scratch org pool. Coverage and JUnit XML as artifacts.

Review
Merge to main

Reviewers see the test results on the pull request itself.

Nimbus, pre-deploy
nimbus release validate

Local gates, then a check-only validation of the same bytes in Salesforce. A signed receipt records what passed.

Salesforce
nimbus release deploy

After approval, quick-deploys exactly the validated payload. Drift guard, promote and rollback.

Security and procurement

Everything below is documented on the security page and in the DPA.

Read the security overview
Code never leaves your machines

Apex source, schema and test data are read and executed locally, on the developer's laptop or your CI runner. Nothing is uploaded to Nimbus.

No org credentials required to test

Running the suite needs no connected org, no JWT certificate and no sandbox. Org access is used only for validation and deployment, through the Salesforce CLI you already trust.

Air-gapped and enterprise environments

License validation and network behaviour are documented in full. Enterprise and air-gapped setups are covered on the security page.

Contracts

DPA, subprocessor list, EULA and terms are published. Mutual NDA on request, yours or ours.

License management portal

Assign and revoke seats, license a dedicated CI runner, and see who has what. Included in the Team plan.

Evidence for auditors

Signed release receipts and the on-prem Assurance console give a durable record of what was validated and what was deployed.

Plans

Enterprise setup
A fixed-fee engagement for teams whose Apex is still in the org and whose tests only run there.
$7,500to $25,000, by Apex surface. Two weeks.
Week oneInto source control

Full metadata pull, clean sfdx project layout, a git repository with history, and a team handover.

Week twoNimbus at 95%+ parity

Every test class running locally, gap closure to the parity target, a CI pipeline template, and a written support map.

If the parity target in the SOW is missed, we keep working at no extra cost until it is met. 30-day parity warranty included. Optional support contract $6,000 per year.
Book a setup call
Small · $7,500

Up to about 20K lines of Apex, 200 test classes, single package, no managed-package dependencies.

Standard · $15,000

20K to 100K lines, up to 1,000 test classes, multi-package, up to 2 managed-package stubs, CI for one platform.

Large · $25,000

100K+ lines, unlimited test classes, up to 5 managed-package stubs, CI for two platforms, dedicated Slack channel.

Who this is for

Good fit
Two or more Apex developers, org-first or already source-driven
50+ test classes in production
Tests currently run only against an org, or CI is fragile
Interest in modern DX, unsure how to migrate
Can share the codebase under NDA
Not a fit
Projects under 10 classes
Cannot share code under NDA for legal reasons
Looking for a Salesforce consultancy, not a test runner
Tests that depend mostly on UI, approvals or sharing rules
No appetite to change how the team works

Questions

What does parity actually mean?

For each Apex test, the same pass or fail result as running it against your production org. We run every test in both environments and diff the results. The target, typically 95%, is fixed in writing in the SOW.

What if the parity target is missed?

We keep working at no additional cost until it is met. The engagement is not finished before then, so a refund clause is not needed.

Who owns the work product?

You own the git repository, the migrated source, the CI configuration and every script produced. Nimbus itself is licensed under the plan you subscribe to.

Does it replace our sandboxes?

No. Sharing rules, approvals and UI still need an org, and final validation happens in Salesforce. Nimbus removes the org from the steps where it was only slowing tests down.

Talk to an engineer

Bring a test suite that is slow or flaky today. We will run it on the call and tell you what Nimbus covers and what it does not.

Prefer email: sales@testnimbus.dev

Already a customer: support@testnimbus.dev

We reply within one business day.