engine room

Seven engines.
One binary.

One engine interprets Apex, one translates SOQL, one holds the data, one keeps transactions honest, one runs flows, one replays managed packages, and one gates the deploy. This is the schematic: what each engine does, where the machine stops, and where you meet each part of it.

powertrain · source in, deploy out
apexsoqlsqlrowsgatepayloadflowsreplaysavepointsLOCKSTEPflow runtimeCASSETTErecord & replayERAtransaction fidelityQUILLapex interpreterCARBONsoql translatorLEDGERdata engineSIGNETdeployability

Hover an engine to light its path. Click to pin it.

hover lights an engine’s path · click pins it · the address bar keeps the pinevery edge is a call the binary makes

the manifest

Seven engines, one at a time.

Quill

apex interpreternimbus test

A tree-walking interpreter over a full parse of every class, interface, and trigger in the project — no bytecode, no transpilation, no rewriting of your source. Trigger contexts, static state, async jobs, and exception behaviour follow the platform's order of execution, and errors carry the messages Salesforce raises. The test runner, the debugger, and anonymous execution all run through it.

Carbon

soql translatornimbus test

Translates each SOQL statement into PostgreSQL at the moment it runs: bind variables, parent and child relationship traversal, aggregates and GROUP BY, date literals, and the sharing clauses. Dynamic queries through Database.query take the same path as inline ones, so both see the same semantics. Nothing is stubbed or pattern-matched — the rows come back from a real query planner.

where you meet it

Ledger

data enginenimbus test

An embedded PostgreSQL that Nimbus starts, tunes, and shuts down itself — no Docker, no service to install, no port to claim. It carries the Salesforce data model: standard objects and their fields, the custom objects in your source, field-level security, record types, and rollup summaries. Each test runs inside its own transaction and is rolled back afterwards, so one test never sees another's data.

Era

transaction fidelitynimbus test

Wraps every write so transaction boundaries behave the way the platform's do: savepoints and rollback, allOrNone false, and per-record success and error results on every DML verb. A failure inside a test fails the way the org fails it — caught, partial, or rolled back to the savepoint you set. The bookkeeping stays off the per-statement path, so that fidelity costs no measurable run time.

where you meet it

Lockstep

flow runtimenimbus test

Record-triggered flows, autolaunched flows, and subflows are loaded straight from your metadata and executed in the platform's order-of-execution slots — before-save flows ahead of before triggers, after-save flows after the after-trigger step. They see the same records your Apex sees, and their DML re-enters the same pipeline, so flows, triggers, formulas, and rollups interleave the way they do in an org.

where you meet it

Cassette

record & replaynimbus record

Records a managed package from a real org once — its classes, its constants, and the answer it gives to each call — and writes the tape to disk. After that the package replays offline and deterministically, with no org connection in the loop. The recordings are files you commit, so CI and every developer on the team replay the same answers.

where you meet it

Signet

deployabilitynimbus release validate

Presses the seal on a release. nimbus release validate runs your local gates plus a real Salesforce check-only validation and writes an immutable receipt; after approval, nimbus release deploy ships exactly the payload the receipt names — on any machine. The seal is earned by inspection: the save-time rules Salesforce applies to metadata run locally first, so dangling references, invalid API versions, and compiler rejects surface before anything is pushed.

The receipt is the contract. It records everything the deploy will re-check and expires — ten days by default — and nimbus release deploy accepts only a matching, unexpired one. There is no bypass flag. Where the org-side validation ran tests, the deploy is a quick deploy: Salesforce ships the payload it already checked rather than checking it twice. nimbus validate runs the save-time rules on their own, before any of this; nimbus deploy runs the whole cycle end to end.

limits · what still needs the org

Seven engines cover the layers that make a test meaningful. They do not cover the org. A schematic implies completeness, so this is printed rather than footnoted:

  • 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 — your org is still the source of truth

The full account, engine by engine, is on the comparison page.

Start the machine on your own repo.

One binary, no Docker, no JVM, no org. Install Nimbus, run nimbus test in your project root, and all seven engines are already running.