Nimbus vs scratch orgs

What each one is

Scratch orgs

A scratch org is a temporary, configurable Salesforce org provisioned from your DevHub. It has full platform fidelity: every feature works exactly as it does in production. Each developer typically gets their own, so there's no shared state. The catch: provisioning takes 30 seconds to several minutes, your source has to be pushed, and the org sits behind DevHub's daily and active limits (100 active / 200 per day for most editions).

Nimbus

Nimbus runs a complete Apex interpreter on your machine with an embedded PostgreSQL. SOQL executes as real SQL, triggers fire on DML, flows run from your .flow-meta.xml files, and each test runs in an isolated transaction. It needs no org, no credentials, and no internet connection. Tests typically finish in tens of milliseconds.

Timings and costs

• Test run time, single test: scratch org ~5–15 seconds (deploy + execute + retrieve); Nimbus ~10–200 ms.
• Full suite (1000 tests): scratch org 8–20 minutes; Nimbus 30–90 seconds.
• First-time setup: scratch org 5–30 minutes (config, push, install); Nimbus < 1 minute (single binary).
• Operational cost: scratch org consumes DevHub limits and CI minutes; Nimbus runs on your laptop or CI runner, with no external service.
• Credentials needed: scratch org requires JWT cert, connected app, DevHub access; Nimbus needs none.

Where scratch orgs win

• Full platform features. Sharing rules, Visualforce/LWC rendering, real platform events end-to-end. Nimbus implements some of these, not all.
• Governor-limit fidelity. Heap size and CPU time are measured against Salesforce's own platform hardware. Nimbus can track structural limits (SOQL rows, DML statements) but resource-based limits aren't comparable across machines.
• Pre-deployment validation. The last gate before production, run on a real org to verify the deploy itself works.
• UI work. Anything that requires the org UI to render and respond.

Where Nimbus wins

• Edit-and-run speed. Edit a class, save, and see the results in milliseconds. The same cycle with a scratch org takes minutes.
• Offline. Nimbus runs on a train, on a plane, or in a coffee shop with no Wi-Fi.
• CI without an org. No JWT cert, no DevHub limits, no scratch org pool to exhaust. Standard JUnit XML and Cobertura XML plug into GitHub Actions, GitLab, SonarQube, Codecov.
• AI agents. Agents write, test and fix in a cycle that only works when tests run in seconds. Nimbus gives Claude Code, Cursor, and Copilot that cycle for Apex, the way Python and TypeScript already have it.
• Per-developer cost. No DevHub limit consumed for every developer running tests all day.

How teams use them together

The pattern we see most often:

1. Local development: Nimbus for every test run during active work. Watch mode re-runs affected tests on save.
2. Pull-request CI: Nimbus runs the full suite as the merge gate. JUnit XML + Cobertura plug into the existing CI.
3. Pre-deployment: a scratch org or sandbox runs the same tests as the final platform-fidelity check before promoting to production.

The DevHub-heavy "every PR provisions a scratch org" pattern goes away. Scratch orgs become a deployment-validation tool rather than a development dependency.

What changes when you migrate

# Before: scratch-org loop
sf org create scratch -f config/project-scratch-def.json -d
sf project deploy start
sf apex run test --suite-names MySuite --result-format json --wait 10

# After: Nimbus loop
nimbus test "MySuite.*"

Nimbus reads your sfdx-project.json, classes, triggers, and flows in place. There is no copying, no parallel project, and no separate set of test files. The same @isTest classes that run on the platform run locally.