The local runtime for Salesforce Apex
Your SOQL, your triggers, your flows — even your managed packages, recorded once from your org — executed on your machine, in milliseconds. The write-run-fix loop you repeat forty times a day, with the org out of it. And when tests pass, the same tool ships them: gated deploys, Salesforce validation, release receipts.
prove it on the repo you already have
curl -fsSL https://testnimbus.dev/install.sh | shInstalls in seconds macOS · Linux · Windows No Docker, no JVM
@isTeststatic void recalculatesNetTotal() { Invoice__c inv = new Invoice__c(Amount__c = 100); insert inv; // real DML Test.startTest(); InvoiceService.recalc(inv.Id); // triggers fire Nebula.Logger.saveLog(); // from your org Test.stopTest(); System.assertEquals(119, [ SELECT Net__c FROM Invoice__c WHERE Id = :inv.Id ].Net__c);}why this, why now
Every wait your team treats as normal — the four-minute deploy to test a one-line change, the shared-sandbox data bleed, the CI org ritual — exists because Apex only ran in an org. That constraint is gone. Install Nimbus, point it at the repo you already have, and run the whole suite this morning. When it's green, ship it with the same tool.
the bottleneck
If you wrote Apex today, you also waited today. Push, deploy, wait, repeat — a tax on every single change, for every developer on the team. This is the part of the job Nimbus deletes.
You change one line in a trigger. Push to scratch org. Wait 4 minutes. Tests fail because another developer's test data is polluting the database. Spend 20 minutes debugging someone else's problem. Multiple devs, one environment, constant friction.
New developer joins. Day 1: request org access. Day 3: admin provisions a sandbox. Day 5: they finally run their first test. Five days to run a single test. Every new hire, on every project.
Your pipeline needs a connected org, a JWT cert, a DevHub with available scratch org limits, and a prayer the org pool isn't exhausted. When it breaks — and it eventually does — the failure is rarely in your code. Meanwhile your Java team has Codecov badges that just work.
None of this is the work. It's overhead from the org being in the loop — and it ends the first time you run nimbus test. Install and run your suite now.
Proof, not adjectives
apex-recipes, fflib-apex-mocks, and Nebula Logger run on Nimbus with no source changes — thousands of their own real tests, passing locally. No per-test limits. Run your whole suite.
Verify it yourself:
git clone …/fflib-apex-mocks && cd fflib-apex-mocks && nimbus test "*"the surface
The Apex surface Nimbus executes natively — classes, data, automation, and tests. It grows with every release.
Nimbus runs the ~80% of tests that exercise business logic, SOQL, triggers, and class behaviour. It does not replace your org for:
The org stays the source of truth — and Nimbus now runs that final gate for you: gated deploys with real Salesforce validation. See the full comparison.
the machinery, named
Real execution isn't one trick — it's purpose-built machinery for every layer of platform behaviour. These are the engines inside the binary.
Executes real Apex — classes, triggers, async jobs, order of execution — from a full parse of your source. Built to agree with the platform down to the error messages.
Rewrites every SOQL query as PostgreSQL on the fly — binds, relationship queries, aggregates, sharing. A faithful copy of the platform's query semantics, one sheet down.
An embedded PostgreSQL that behaves like the Salesforce database: standard objects, field-level security, record types, rollups. No Docker, no setup, no org.
Savepoints, partial success, rollback. DML that fails inside a test fails exactly the way the platform fails it — caught, partial, or rolled back — without the speed tax.
Record-triggered and autolaunched flows fire in the same order-of-execution slots the platform uses — in step with triggers, formulas, and rollups.
Records managed-package calls from a real org once, then replays them offline forever. Written to disk, checked into git, deterministic.
The ship-gate: save-time rejects caught locally, green validations sealed into release receipts, deploys gated on exactly that payload.
One binary, the whole toolchain
A debugger, a language server, mutation testing, coverage, AI agents — none of it was possible while the org was in the loop. Move execution to your machine and the whole toolchain comes with it. And once every gate runs locally, the deploy itself can be gated too.
Classes, SOQL, DML, and triggers execute against an embedded PostgreSQL.
nimbus record captures a package's classes, values, and per-call answers from your org once. NPSP and Nebula Logger code then runs locally.
Record-triggered, autolaunched, and screen flows run alongside your Apex.
Code lenses, inlay hints, semantic tokens, and call hierarchy in any LSP editor.
First-class plugins with full parity — inline results, run buttons, coverage gutters.
Mutates your code and checks your tests catch it — a category first for Apex.
Line and branch coverage. JUnit XML, Cobertura, and HTML into any pipeline.
Breakpoints and variable inspection over DAP — live, not log replay.
Structured OpenTelemetry traces of every call, query, trigger, and branch.
Test explorer, coverage, schema browser, and an Apex REPL — no editor needed.
Agents call the runtime natively over JSON-RPC for tight write-test-fix loops.
A Salesforce-compatible REST and gRPC Pub/Sub server, on localhost.
Warm the whole codebase once; every run after that starts in milliseconds.
nimbus deploy: local gates, Salesforce validation of the same bytes, then deploy. One command.
Validate once, approve, quick-deploy exactly the validated payload — portable across CI machines.
Any sf command through nimbus sf — arguments, prompts, and exit codes preserved.
The modern way to develop Apex
Four capabilities that reshape Apex development day to day — real execution, live debugging, mutation testing, and traces. Each links to the full story.
Your SOQL actually runs. Your triggers actually fire. Your DML actually persists. Nimbus executes Salesforce Apex against a real embedded PostgreSQL database — not a simulated environment. No fake return values, no stubbed runtime. And no speed tax: a typical test still completes in tens of milliseconds.
Why an embedded databaseThe Apex Replay Debugger works from a log after execution. Nimbus debugs live — set breakpoints, step through code, inspect variables in real time. Supported in VS Code and JetBrains IDEs.
See the debuggerNimbus mutates your code — flips operators, negates conditions, changes returns — and checks if your tests catch it. A category first for the platform. 75% coverage means nothing if mutants survive.
How mutation testing worksEvery test run produces a structured OpenTelemetry trace — method calls, SOQL, DML, triggers, branches, variable assignments — visualized as an interactive tree. Not a 40,000-line debug log.
Explore traces & analyticsFrom local pass to production
The tool that watched every test pass is the right tool to deploy them. nimbus deploy snapshots your source, runs your local gates, validates the identical payload in Salesforce, then deploys it — one command, receipt included. nimbus release splits validate from deploy so an approval can sit between them, in CI or in your editor.
And nimbus sf passes any Salesforce CLI command through unchanged — every current and future sf capability, one entry point.
# One command: gates → org validation → deploy
nimbus deploy --target-org staging --source-dir force-app
# Or split it: validate now, approve, deploy later
nimbus release validate --release-profile production
nimbus release deploy --receipt .nimbus/releases/rel_01J9.json \
--confirm-production
# Any sf command, unchanged
nimbus sf org login web
nimbus sf data query --query "SELECT Id FROM Account"The safe path is the short command — and it's Free.For the whole team
Each release leaves a signed receipt: what was tested, who validated it, who deployed it, whether the org drifted, and a change reference — tamper-evident, and true whether you read it on the command line or hand it to an auditor.
nimbus assurance opens that evidence to the people who read releases but never open a terminal — release managers, auditors — in a console that verifies every signature live. It runs read-only on your own network. Your code and receipts never leave your walls; there is nothing to trust us with.
# A team console over every release's evidence
nimbus assurance
# Verified live in the browser: who validated,
# who deployed, checks, drift, signature status.
# Archive the evidence for retention — and
# re-verify it, offline, years later.
nimbus release export --output evidence-Q3.json
nimbus release verify-export evidence-Q3.jsonRuns inside your walls. Nimbus hosts nothing.the boundary
Nimbus owns the loop — the org stays the platform. Here's the contrast in one screen — full comparison.
Configuration
In Salesforce, your test environment is configured through Setup UI and Custom Settings — none of it in source control, none of it shared with your team. Nimbus flips that. One nimbus.properties file, committed to your repo, configures everything: governor limits, org defaults, custom setting seeds, database settings.
Profiles let CI enforce strict governor limits while local dev stays relaxed. Same binary. Same file. No wrapper scripts.
# Commit this to your repo
nimbus.governor.mode=warn
nimbus.org.currency=EUR
nimbus.org.timezone=Europe/Berlin
# Seed custom settings - no @testSetup boilerplate
nimbus.seed.org-default.TriggerSettings__c=IsEnabled__c=true
nimbus.seed.org-default.FeatureFlags__c=NewUI__c=false
# CI: strict enforcement, no browser
%ci.nimbus.governor.mode=strict
%ci.nimbus.test.parallel=2
%ci.nimbus.devui.open-browser=false
%ci.nimbus.db.url=${DATABASE_URL}NIMBUS_PROFILE=ci nimbus testWhy fast, local Apex matters now
Tools like Claude Code, Cursor, and Copilot work in write-test-fix loops. That loop only works when "run tests" takes seconds, not minutes. An AI agent can generate a trigger handler in seconds — but verifying it still means deploying to an org.
nimbus test. Local testing makes Apex accessible to the same agentic workflows that work for every other language.For tech leads
Nimbus runs the 80% of tests that exercise business logic, SOQL, triggers, and class behavior. Sharing rules, UI, and approvals still need an org. We list every gap on the comparison page — no hand-waving.
No — not where it counts. A typical Salesforce Apex test on Nimbus completes in tens of milliseconds, real SOQL and DML included, and suites of thousands of tests finish in seconds. The embedded PostgreSQL is stripped down and tuned for test workloads (unix socket, fsync and WAL off), and in head-to-head suite runs Nimbus finishes entire OSS suites that in-memory Apex simulators time out on. The real database buys correctness; it does not cost you speed.
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 for production.
Both ends of it. Pre-merge: nimbus test in CI, no connected org — JUnit XML and Cobertura drop into the tools you already run. Pre-deploy: 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 that validated payload. The raw sf deploy stays available, spelled explicitly.
pricing
For individual developers
nimbus deploy)nimbus sf)Free · no card required
nimbus daemon)nimbus serve) — REST + Pub/Sub gRPCget started
The Free tier is live now — install in one line. Sign up for a free Pro license, and join the Slack to ask questions and shape what's next.