Nimbus runs your Apex tests and your Salesforce flows on your machine, without an org.

Apex classes, SOQL, DML, triggers and Salesforce flows execute for real against an embedded database. A typical test finishes in tens of milliseconds instead of a four-minute round trip. When you are ready to ship, the same tool validates in your org and deploys exactly the bytes that passed.

curl -fsSL https://testnimbus.dev/install.sh | sh
nimbus test InvoiceServiceTest
PASS recalculatesNetTotalPASS rejectsNegativeAmount
53 ms
no org round-trip
RuntimeRuns on an embedded database. Nothing to install besides Nimbus.
ExecutionApex, SOQL, DML, triggers and Salesforce flows execute for real.
CIWrites JUnit XML and Cobertura for your CI.
PrivacyYour source and schema stay on your machine.

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×

What runs locally

Nimbus parses every class, interface, trigger and flow in the project and interprets it directly. There is no transpilation step and nothing is stubbed.

Language
  • Classes, interfaces, enums
  • Inheritance and polymorphism
  • Generics and typed collections
  • Exception handling
  • All Apex annotations
Data
  • SOQL queries
  • DML: insert, update, delete, upsert
  • Bind variables
  • Aggregate functions
  • Relationship queries
Automation
  • Before and after triggers
  • Record-triggered flows
  • Autolaunched flows and subflows
  • Flow formulas and decisions
  • Platform event flows
Testing
  • @isTest and @testSetup
  • System.assert variants
  • Test.startTest / stopTest
  • Stub API and ApexMocks
  • Per-test transaction isolation

Compared with the usual ways of running Apex tests

Full comparison, including what Nimbus cannot do
Today
With Nimbus
Scratch orgs
Push the source, wait, run the tests, wait again. Two to ten minutes per cycle, and DevHub limits on top.
Nothing to push. The tests run against the embedded database in milliseconds.
ApexMocks
Everything is stubbed, so the tests pass while the SOQL, triggers, flows and DML they depend on go untested.
The SOQL, DML, triggers and flows execute against a real database, at about the speed of a mocked test.
Sandbox CI
A JWT certificate, a connected org and a scratch org pool, and failures that have nothing to do with your code.
Nimbus writes JUnit XML and Cobertura, which GitHub Actions, GitLab, SonarQube and Codecov already read.
Deploying
sf project deploy ships whatever is in the worktree, which may not be the revision the tests ran against.
nimbus deploy snapshots the payload, runs the local gates, validates that exact payload in Salesforce and then deploys it, with a receipt.

Six things worth checking before you trust it

The SOQL, DML, triggers and flows actually run

Nimbus executes Apex and flows against a real embedded PostgreSQL. Queries return rows, triggers fire, record-triggered flows run and DML persists inside the test transaction. There is no simulated runtime and no stubbed return value, and a typical test still completes in tens of milliseconds.

Why an embedded database
Salesforce flows execute locally, beside the Apex

Nimbus reads the flow metadata in your repo and runs it. Record-triggered flows fire on DML in the platform's order of execution, autolaunched flows and subflows run with their decisions and formulas, and platform event flows subscribe locally. Nothing is deployed and the test class needs no changes.

How flow execution works
A live debugger, in VS Code and JetBrains Pro

The Apex Replay Debugger works from a log after the fact. Nimbus attaches to the running test, so you get breakpoints, stepping and variable inspection while it executes.

See the debugger
Mutation testing for Apex Pro

Nimbus changes your code in small ways, flipping operators, negating conditions and altering return values, then reruns the tests to see whether they notice. 75% line coverage says nothing about whether a test would fail when the code is wrong.

How mutation testing works
A structured trace of every run Pro

Each run produces an OpenTelemetry trace of method calls, SOQL, DML, triggers, branches and assignments, shown as a tree you can expand. It replaces reading a 40,000-line debug log.

Explore traces and analytics
Local and org results, compared Pro

nimbus compare runs the same tests in a connected org and diffs the outcomes, governor usage and traces against the local run. Fidelity is something you check on your own code rather than something we claim.

The org parity record

What still needs an org

Nimbus covers the tests that exercise business logic, queries and automation. These do not run locally.

  • OWD and role-hierarchy sharing (the with sharing keyword is enforced)
  • Approval processes, assignment rules, validation-rule packages
  • Lightning UI / browser testing
  • Final pre-deployment validation, which still happens in your org. nimbus deploy runs that gate for you.

Pricing

Every developer gets Pro free during the beta.

Free

$0

For individual developers

  • Apex runtime, real execution
  • Unlimited test runs
  • SOQL, DML, triggers and flows
  • Code coverage (console, JSON, HTML)
  • Governor limit enforcement
  • Gated deploys (nimbus deploy)
  • Salesforce CLI pass-through (nimbus sf)
  • VS Code and JetBrains integration
  • 1 machine
  • Community support
Install
For larger teams, or if your Apex is not in git yet:Nimbus for teams

Questions

What about platform fidelity?

Nimbus runs the tests that exercise business logic, SOQL, triggers, flows and class behaviour. Sharing rules, UI and approvals still need an org. Every gap is listed on the comparison page.

Is a real database slower than an in-memory runtime?

No. A typical test completes in tens of milliseconds, real SOQL and DML included. The embedded PostgreSQL is tuned for test workloads, with a unix socket and fsync and WAL switched off. In head-to-head runs Nimbus finishes whole open-source suites that in-memory Apex simulators time out on.

What runs locally versus on Salesforce?

Everything Nimbus supports runs on the developer machine. No source code or schema leaves the laptop. The org remains the deployment target and the system of record.

How does this fit a release pipeline?

Pre-merge: nimbus test in CI with no connected org. JUnit XML and Cobertura go to the tools you already run. Pre-deploy: nimbus release validate runs the local gates plus a real Salesforce check-only validation and writes a receipt. After approval, nimbus release deploy ships exactly that payload.

Install

Nimbus is a single binary for macOS, Linux and Windows. The Free tier needs no account and no card. During the beta, sign up for a free Pro license.

Questions go to the Slack or to support@testnimbus.dev.

curl -fsSL https://testnimbus.dev/install.sh | sh
then: cd your-sfdx-project && nimbus test "*"