Most Salesforce teams treat the org as the center of their workflow. It's the only way they've ever worked. But there's a reason the rest of the software industry moved away from this model - and Salesforce developers deserve the same shift.
It's 2:15 PM. You changed two lines in a trigger handler. You push to your scratch org. You wait. The deploy takes 4 minutes. You run the tests. That takes another 3 minutes. One fails - not because of your change, but because another developer's test left dirty data in the org. You spend 20 minutes figuring that out. By 2:45 PM, you still haven't validated your two-line change.
This isn't a bad day. This is every day for most Salesforce teams. When the org is the source of truth, every feedback loop runs through it - and every feedback loop is slow, shared, and fragile. You stop refactoring because it's too risky. You batch changes because deploys are expensive. You skip tests because running them takes too long.
Source-driven development flips this: your code is the source of truth, the org is a deployment target, and your local machine is where the real work happens. No deploy to test. No shared state. No waiting.
The pattern is universal: write code locally, run tests locally, deploy when ready. Salesforce is the only major platform that made the runtime itself a remote dependency.
mvn testJUnit runs against a local JVM. No remote server required. Maven Surefire produces reports, CI picks them up. This has been the default since 2002.
pytestpytest runs entirely locally. No cloud, no account, no deploy step. Tests are just Python functions. The feedback loop is instant.
jest --coverageJest, Vitest, Mocha - all local. Node.js is the runtime, your machine is the execution environment. Watch mode reruns in under a second.
go test ./...go test is a first-class language feature. Parallel by default, no config file needed, results in milliseconds. The toolchain ships with the runtime.
bundle exec rspecRSpec runs locally against a local database (SQLite or Postgres). Rails' test suite philosophy has always been: own your feedback loop.
cargo testTests are compiled and executed locally by Cargo. No external dependency, no deploy. If it compiles and tests pass, you ship.
In every one of these ecosystems, the test runtime is local. Salesforce was the only exception - until now.
The common pushback: Apex is tightly coupled to the platform. Governor limits, metadata, sharing rules, triggers - you need the org to test. That was true for a long time. Not because it was impossible to solve, but because no one had built the solution yet.
Java developers faced the same argument. Their answer wasn't "you need the production server to test." They built local alternatives - H2, Testcontainers, in-memory databases. The tests ran locally, the deploys happened when ready.
Nimbus does the same for Apex. Real SOQL translated to SQL, real DML against a local database, real triggers firing in the right order. The 80% of tests that exercise business logic, queries, and triggers work locally. The other 20% - complex sharing, async, approval processes - that's still where scratch orgs earn their keep.
The difference: you stop waiting on the org to tell you if the code is correct. You know before you deploy.
Nimbus doesn't mock your code or stub your org. It runs a complete Apex runtime locally - the same semantics, the same behavior, just on your machine. And in an era where AI agents write code that needs instant verification, that speed isn't just convenient - it's essential.
Nimbus embeds an Apex interpreter and a local PostgreSQL instance. Your SOQL queries execute, your triggers fire, your Flows run, your DML operations persist - all locally. Record-triggered flows, autolaunched flows, platform event flows - they all execute from your .flow-meta.xml files. Run from VS Code, IntelliJ, the terminal, or the browser-based Dev UI. No org. No credentials. No latency.
Nimbus reads your SFDX project structure directly from the filesystem. The code in your repo is what runs. No sync step, no push, no retrieve. What you see in your editor is what executes. The corollary is equally important: if metadata exists only in the org - a field added through Setup, a Flow built in the browser - Nimbus won't find it. That's not a limitation. It's the discipline source-driven development enforces.
The Apex Replay Debugger replays from a downloaded log. Nimbus debugs live - breakpoints pause real execution, you step through code in real time, and structured traces give you a hierarchical view of every method, query, and trigger with precise timing. No log download, no checkpoint setup.
No scratch orgs, no sandboxes, no credentials in your pipeline. Nimbus produces JUnit XML and Cobertura coverage - the same formats SonarQube, Codecov, and GitHub quality gates already consume. Mutation testing (Pro) goes further: it verifies your tests actually catch bugs, not just that lines were executed. Your Salesforce project gets the same CI infrastructure every other team already has.
If it's not in your repo, it doesn't exist. Metadata changed directly in the org - through Setup UI, the Flow Builder, the object manager - won't be visible to Nimbus until it's retrieved and committed. For teams transitioning from org-first development, sf project retrieve start brings all metadata into the repo. nimbus test --fetch-missing -o <org> is a complementary shortcut: it fetches only the metadata your tests actually reference, re-runs, and lets you iterate without a full retrieve upfront. Either way, once everything is in the repo, no developer ever needs org access to run tests.
Salesforce is a multi-tenant platform. Every test run competes for shared compute, shared database, and shared network. Your laptop doesn't have that problem - dedicated CPU, local SSD, zero network latency, no tenant queue. With Nimbus, your test speed is determined by your hardware, not Salesforce's infrastructure.
Point Nimbus at your SFDX project and run your tests locally. No org, no account, no setup. See how fast your feedback loop can actually be.