Every Salesforce developer knows the wait. You change three lines of Apex, run your tests, and then go make coffee, because deploying to a scratch org and running the suite takes minutes. There is nothing useful you can do in that gap except lose your train of thought.

I got tired of that gap, so I built Nimbus. It runs Apex tests locally, with no org and no Docker, in about a second.

This post is about how it works and what surprised me along the way.

The problem with the feedback loop

Apex doesn't run anywhere except Salesforce. That is the whole premise of the platform: your code lives next to the database, the metadata, and the governor limits. It's a feature, not an accident.

It's also why the inner loop is slow. To run a single test method the usual flow is: push your code to a scratch org or sandbox, wait for the deploy, enqueue the tests, poll for results, then read the failures and start over. Every round trip is bound by the network and the org. On a real project the cycle gets long enough that you stop running tests after every edit, which is exactly when they'd be most useful.

What I wanted was the thing every other language already has. Save the file and get instant feedback.

What "local" actually requires

To run an Apex test with no org, you have to reimplement a surprising amount of the platform. You need a lexer and parser for the language, including classes, triggers, and annotations. You need an interpreter that actually executes the AST: control flow, exceptions, collections, static state, the type system. You need a database that behaves enough like Salesforce's to back DML and SOQL. You need a SOQL engine that turns Salesforce's query language into something a real database understands. And you need the platform semantics, which is the part that bites: trigger order of execution, @testSetup, test isolation, and a long list of quirks.

That last one is where most of the real work lives, and it's the part you can't shortcut. Apex is full of behavior that only matters once you've been burned by it. I'll get to some of those.

The stack

Nimbus is written in Go. The shape of it looks like this:

Apex source
   │
   ▼
 Lexer  ──►  Parser  ──►  AST
                            │
                            ▼
                      Interpreter  ◄──►  Local PostgreSQL (embedded)
                            │                    ▲
                            ▼                    │
                       SOQL engine ──────────────┘

A few of the choices behind it.

It's a tree-walking interpreter rather than a bytecode VM. Apex test suites aren't tight numeric loops; they're shaped by DML and queries. A tree-walker is much easier to get correct, and correctness is the entire point. If a local runtime gives a different answer than the org, it's worse than useless, because now it's lying to you. So I optimized for matching Salesforce's behavior, not for raw speed.

It embeds PostgreSQL, with no Docker. An early version reached for a containerized database, and that's a non-starter for a dev tool. Asking developers to run Docker just to execute a unit test is the kind of friction that quietly kills adoption. Nimbus ships a single binary with the database embedded. Nothing to install, nothing to start, nothing to clean up.

It translates SOQL to SQL on the fly. SOQL looks like SQL but it isn't. Relationship traversal like Account.Owner.Name, child subqueries like SELECT Id, (SELECT Id FROM Contacts) FROM Account, polymorphic fields, semi-joins: all of it gets rewritten into PostgreSQL at query time. This is one of the harder corners, and one of the most important to get exactly right, because SOQL shows up in nearly every Apex test.

The interesting part: platform semantics

Writing a parser is a known quantity. The difficulty, and honestly the fun, is in reproducing the parts of Apex that live in the runtime's behavior and not in any document.

Here are a few that cost me real time.

Trigger order of execution

When you insert a record, Salesforce runs the before triggers, saves, then runs the after triggers, and the context variables (Trigger.new, Trigger.oldMap, the boolean flags) have to be correct at each stage. Recursive DML inside a trigger needs to fire the next trigger. Get the ordering subtly wrong and a whole class of tests passes locally but fails on the platform, which is the worst outcome you can have.

Map case sensitivity

This one is a good story, and it doesn't have a clean ending. Apex's Map<String, V> is case sensitive. Put 'Foo' and 'foo' in the same map and you get two entries, and get('FOO') returns null. That's the platform behavior, confirmed against a live org.

The wrinkle is that a fair amount of real-world Apex leans, usually without meaning to, on case insensitive lookups, especially code keyed on field API names. And the platform itself is inconsistent about it: the describe maps like Schema.getGlobalDescribe() and fields.getMap() actually are case insensitive on the org, even though a plain Map<String, V> is not.

I have the spec-correct, case sensitive version mostly built and gated behind a flag. The honest reason it isn't the default yet is that flipping it regresses a handful of tests, around eight at last count, across libraries like apex-rollup and Nebula Logger, all in user code that happens to rely on case-only key collisions collapsing. The platform maps are already flagged case insensitive to match the org. So today Nimbus is knowingly divergent on the plain Map<String, V> default, and the tradeoff is explicit: shipping the strictly-correct behavior with regressions is a worse signal to a developer than matching what their existing code expects while the remaining cases get worked through one at a time. I'd rather tell you that than pretend it's settled.

Id 15 vs 18 characters

Salesforce Ids come in two forms. The 15-character version is case sensitive, and the 18-character version is case insensitive with a checksum on the end. Code casts and compares them in ways that depend on which form you have. A single decision, like whether (Id) '001...15chars' expands to 18 characters, pushes dozens of tests in opposite directions depending on the codebase. There's rarely a free answer. You pick the behavior that matches the most real code and you write down the tradeoff.

JSON serialization key order

Here is one almost nobody thinks about until a test fails on it. When you call JSON.serialize on a Map<String, V>, the order the keys come out in is not arbitrary, and it is not insertion order either. On a live org, the keys come out in reverse insertion order. So a test that builds a map and then asserts on the exact serialized string is implicitly depending on that ordering, whether the author knew it or not.

Nimbus originally emitted keys in plain insertion order, which is the obvious thing to do and the wrong thing to do, and any test asserting on a serialized map string failed against it. The fix was to match the org's reverse-insertion-order behavior, verified across maps of several sizes. As a separate quirk, string concatenation on a map ('' + map) sorts the keys alphabetically instead, which is a different code path again. None of this is documented. You find it by serializing a map locally, serializing the same map on an org, and diffing the two strings.

Static state and test isolation

Each test method has to run as if nothing else ever happened: fresh static variables, a clean database, and its own transaction that rolls back when the method ends. Data created in @testSetup has to be visible to every method, but changes one method makes can't leak into the next. Reproducing that isolation model, and the static-reset rules around it, is essential to matching how Salesforce scopes a test run.

None of this is written down in a tidy spec. You learn it by running large, real, messy codebases and watching what breaks.

Does it actually work?

That's the question that matters, and the only honest way to answer it is to point it at real Apex and count.

I've been running Nimbus against well-known community libraries and full application codebases, the kind with thousands of test methods, heavy trigger frameworks, mocking libraries, and dynamic SOQL. The bar I hold it to is simple: the same pass or fail result you'd get in the org, just faster.

When a test passes in the org and fails in Nimbus, that's a bug in Nimbus. No exceptions. Each one is a case study: a missing builtin, a semantic mismatch, an edge in the SOQL translator. Tracking those down is how the runtime earns its fidelity, and the compatibility surface is large enough that this is the ongoing work.

Why local-first matters beyond speed

Speed is the headline, but it isn't the only thing you get once Apex runs on your own machine.

Because Nimbus understands Apex deeply enough to execute it, it can also back a language server. That means diagnostics, code lenses, inlay hints, and semantic tokens driven by the same engine that runs the tests.

It also makes CI simpler, which is the part I think is genuinely underrated, so it gets its own section below.

And it makes coverage something you can iterate on. Per-line coverage collected locally and instantly lets you close gaps in a tight loop, instead of deploying just to find out you missed a branch.

What this does to your pipeline

Salesforce CI is usually built around an org. A typical pipeline authenticates to the Dev Hub, spins up a scratch org, pushes the source, runs the tests, scrapes the results, and tears the org down. It works, but it's slow, it needs credentials sitting in your secrets, and scratch org limits are a real constraint when a lot of builds run at once.

If the tests run locally, all of that disappears. The pipeline just fetches a binary and runs it. There's no org to authenticate to, no scratch org to provision, no credentials beyond the Nimbus license key, and nothing to clean up afterward.

I put together a demo repo called BerlinBrew, a fictional coffee-subscription Salesforce project, to show the whole thing end to end. You can clone it and watch the pipeline run for yourself. The GitHub Actions job is short enough to read in one go. It installs Nimbus, caches the embedded PostgreSQL binaries so cold starts stay fast, and runs the suite:

- name: Install Nimbus
  run: |
    curl -fsSL https://install.testnimbus.dev | sh
    nimbus --version

- name: Run Apex tests
  env:
    NIMBUS_LICENSE_KEY: ${{ secrets.NIMBUS_LICENSE_KEY }}
  run: |
    nimbus test "*" \
      --coverage --coverage-report coverage.xml \
      --results-xml results.xml

The version is pinned in an environment variable so builds are reproducible and you bump it on purpose. The embedded Postgres binaries get cached under ~/.nimbus/pg, keyed on the Nimbus version, so a bump busts the cache automatically.

The two output files are the part that makes this drop into existing tooling without any glue. results.xml is JUnit, so any test reporter understands it. In BerlinBrew it's fed to a standard publish-test-results action that posts a check on the pull request. coverage.xml is Cobertura, so the coverage gate is just a few lines parsing lines-covered and lines-valid and failing the build under 75 percent, which is the same threshold Salesforce enforces for a production deploy:

- name: Enforce coverage threshold
  run: |
    covered=$(grep -m1 -oE 'lines-covered="[0-9]+"' coverage.xml | grep -oE '[0-9]+')
    valid=$(grep -m1 -oE 'lines-valid="[0-9]+"' coverage.xml | grep -oE '[0-9]+')
    # fail the build if covered/valid is under the threshold

One more thing the demo leans on: a CI profile. Nimbus reads a nimbus.properties file, and you can scope settings to a profile that only activates in the pipeline. BerlinBrew uses it to turn governor limits from a warning into a hard error and to run tests across four workers:

%ci.nimbus.governor.mode=strict
%ci.nimbus.test.parallel=4

So locally you get lenient, fast feedback, and in CI you get strict governor enforcement that catches the kind of limit problems you'd otherwise only discover on deploy. Same binary, different posture. None of it touches an org.

What I learned

A few things I'd tell myself at the start.

Correctness is the product. A fast runtime that lies is worse than a slow org that doesn't, and almost every design decision bent toward matching the platform's observed behavior.

The spec is a starting point, not the destination. Where the docs and the runtime disagree, the runtime wins, because people are running code that already works on the runtime.

Real codebases are the only real test suite. Hand-written sample tests find none of the interesting bugs. Pointing the thing at thousands of community tests finds all of them.

Friction is fatal for dev tools. "Install Docker first" or "spin up an org" is enough to lose people. One binary and zero setup, or it doesn't matter how clever the internals are.

Try it

Nimbus runs your existing Apex tests locally, with no org and no Docker, from a single binary. You can grab it and read the full CLI reference at testnimbus.dev.

# from your Salesforce project root
nimbus test

If you spend your day in the Apex inner loop and you're tired of the gap, point it at your codebase and tell me what breaks. The bugs you find are the roadmap. Docs and install instructions live at testnimbus.dev.