Frequently asked questions
"Does it actually work?" "What doesn't it support?" "Can I trust it?" Fair questions - here are honest answers.
Nimbus runs your Apex tests locally — no Salesforce org, no scratch org, no Docker. The questions below cover how accurate the local runtime is, which Apex language and platform features are supported today, how licensing and pricing work, whether your source code ever leaves your machine, and how Nimbus fits into CI/CD pipelines and AI coding workflows.
Nimbus is fast, and the embedded PostgreSQL is not a bottleneck. A typical Salesforce Apex test completes in tens of milliseconds — real SOQL and DML included — and suites of thousands of tests finish in seconds. In head-to-head suite runs, Nimbus completes entire open-source test suites (all 321 apex-recipes tests, all 1,351 Nebula Logger tests) while in-memory Apex simulators hit per-run caps and timeouts before finishing. Measured wall-clock, the real database does not cost you speed.
Why not: the per-query overhead of a separate database process is measured in microseconds, and Nimbus strips it aggressively — the embedded PostgreSQL talks over a unix domain socket with a binary protocol, and durability features that make no sense for a test runner (fsync, WAL, autovacuum) are turned off. What remains is dwarfed by what the real database buys: savepoints, deferrable constraints, and concurrent writes, which are exactly the behaviors non-trivial Apex test suites depend on.
The full engineering breakdown — including what PostgreSQL costs per query and why we chose it anyway — is on the Why PostgreSQL page.
Salesforce Apex. Nimbus is a local runtime and test runner for Apex, the programming language of the Salesforce Platform — the language you write triggers, classes, and @isTest methods in.
It has nothing to do with Oracle APEX (Oracle Application Express), which is an unrelated low-code app-building product for Oracle databases. If you're searching for Oracle APEX tooling, Nimbus isn't it. If you write Salesforce Apex, Nimbus runs it on your machine — no Salesforce org required.
Nimbus runs a complete Apex interpreter, not a mock or stub layer. SOQL queries are translated to real SQL and executed against an embedded PostgreSQL database. Triggers fire automatically on DML operations with full context variables (Trigger.new, Trigger.old, Trigger.newMap, Trigger.oldMap). Test context isolation works - Test.startTest() and Test.stopTest() behave as expected.
The runtime is designed to match Salesforce behavior for the patterns that matter most in unit and integration tests: class execution, DML, SOQL, triggers, collections, exceptions, and annotations.
One honest limitation: some governor limits - heap size, CPU time, and a few others - cannot be faithfully replicated in a local runtime. Salesforce measures these against its own platform execution model running on consistent server hardware. Nimbus runs on your machine, on hardware that varies from a MacBook to a CI runner to a Windows laptop. Even if CPU time could be measured precisely, the numbers would be meaningless compared to what Salesforce enforces. Nimbus tracks what it can (SOQL row counts, DML statements, query rows), but resource-based limits will never be 100% consistent or accurate. For the vast majority of unit and integration tests, this doesn't matter. For tests that specifically probe limit behavior, a real org remains the authoritative environment.
Nimbus supports a broad set of Apex language features:
- Classes, interfaces, enums, and abstract classes - Inheritance, polymorphism, and method overloading - Generics and typed collections (List, Set, Map) - All trigger events (before/after insert, update, delete, undelete) - Flow execution: record-triggered flows, autolaunched flows, platform event flows, subflows, decisions, loops, record lookups, formulas, collection processors - SOQL queries with bind variables, relationship queries, aggregates, and subqueries - DML operations (insert, update, delete, upsert, undelete) - Exception handling (try/catch/finally, custom exceptions) - Annotations (@isTest, @testSetup, @isTest(SeeAllData=true)) - System.assert, System.assertEquals, System.assertNotEquals - String, Integer, Decimal, Date, DateTime, Boolean, and Blob types - Static and instance methods and fields - Access modifiers (public, private, protected, global) - Local debugging: breakpoints, step in/over/out, variable inspection - Structured execution traces with 5 verbosity levels (method calls, SOQL, DML, triggers, timing) - System.debug() with structured output (not just text - typed values, nested objects, collections) - VS Code extension with CodeLens, Test Explorer, coverage gutter icons, governor limits, SOQL preview, trace viewer - JetBrains / IntelliJ plugin with the same feature set - Browser-based Dev UI dashboard (nimbus dev) with real-time test results, schema explorer, and anonymous Apex execution - Mutation testing (Pro): automatically mutates your code and verifies your tests catch each change - a first for Apex
Architectural limitations - these can never be fully replicated in a local runtime:
- Governor limits based on platform resources (heap size, CPU time) - Salesforce measures these on consistent server hardware against its own platform runtime. Nimbus runs on your machine, which varies. Even if the numbers could be tracked precisely, they would not be comparable to what Salesforce enforces. SOQL row counts and DML statement counts are tracked; resource-based limits are not.
Not yet implemented - planned for future releases:
- Visualforce and Lightning Web Component rendering - Approval processes and workflow rules - Platform events (publishing works, subscription does not) - Certain aggregate edge cases - Metadata API operations
The runtime is actively expanding - each release adds more coverage. For features that require full platform fidelity, complement Nimbus with scratch org testing for that subset.
Yes - and this might be the most impactful use case. Today, running Apex tests in CI means maintaining a connected org, a JWT cert, a DevHub with scratch org limits, and a pipeline that breaks whenever any of those expire. With Nimbus, none of that exists. No org, no credentials, no scratch org pool. Install the binary, point it at your repo, run tests.
Nimbus produces the same standard output formats that every other language ecosystem uses: JUnit XML for test results and Cobertura XML for coverage. These plug directly into SonarQube, Codecov, GitHub quality gates, GitLab CI, CircleCI, Azure Pipelines, and any other tool that consumes industry-standard formats. Your Salesforce project finally gets the same quality infrastructure that your Java and JavaScript teams have had for years.
No sandboxes needed. No scratch orgs needed. Your merge gates validate real Apex behavior, not just "did the deploy succeed."
Yes. nimbus deploy is a gated one-shot deployment: it snapshots your selected source into a content-addressed bundle, runs Nimbus validation and your configured local tests against that bundle, validates the identical bytes in the target org with a real Salesforce check-only validation, and only then deploys. It's a Free command — the safe default is never paywalled.
For release processes with an approval step, nimbus release validate writes an immutable receipt (bundle digest, gate results, the Salesforce validation job ID and its quick-deploy expiry), and nimbus release deploy later ships exactly that validated payload — quick-deploying the org-side job where Salesforce supports it. Receipts are portable CI artifacts: validate on one runner, approve, deploy from another. Ready-made templates exist for GitHub Actions, GitLab CI/CD, Azure DevOps, and generic shell.
And nimbus sf passes any Salesforce CLI command through unchanged, so the raw ungated deploy — nimbus sf project deploy start — stays available, spelled explicitly.
Nimbus doesn't replace scratch orgs - it frees you from needing one just to develop. With Nimbus, you can write and test Apex code on your laptop, on a plane, or on any machine - no internet, no org access, no credentials required.
Use Nimbus for the 80% of your work: business logic, SOQL queries, triggers, and class behavior. Develop anywhere, iterate freely, and deploy whenever you're ready. Scratch orgs remain available for the 20% that require full platform features like complex sharing rules or approval processes.
The key shift: an org becomes a deployment target, not a development dependency.
Nimbus has three tiers (plus Enterprise):
Free ($0, forever) - Full Apex runtime, unlimited test runs, SOQL/DML/triggers, code coverage (console, JSON, HTML), governor limit enforcement, VSCode integration, 1 machine.
Pro ($199/year, or $19/month) - Everything in Free plus background daemon (instant startup), parallel test execution, watch mode, debugger with breakpoints, mutation testing, coverage gutter icons in VSCode, org fallback. 1 developer, 3 machines.
Team ($999/year, or $99/month) - Everything in Pro plus JUnit XML and Cobertura output (for SonarQube, Codecov, GitHub Actions, etc.), pooled team seats (up to 10 developers, 3 machines per seat), a dedicated CI runner license that activates on unlimited ephemeral build agents (no per-runner machine slot), license management portal, and priority email support.
Enterprise (custom) - Unlimited seats, SSO/SAML, audit logging, SLA, on-premise deployment, and custom contracts.
The Free tier is fully functional - coverage and governor limits work the same as in Pro. Pro adds productivity features (daemon, parallel, watch, debugger, mutation); Team adds CI-integration formats, shared seats, and priority support.
No. Everything runs entirely on your machine.
Nimbus is a local binary. Your Apex source code is read from the filesystem, parsed in-process, and executed against a local embedded PostgreSQL database. No code is transmitted to any server, and no cloud service is involved in test execution.
Nimbus makes license-validation calls for paid features and sends one privacy-minimal product activation event by default. Licensed headless CI sends a separate de-duplicated activation event. Neither includes code, file paths, test names, Salesforce data, repository details, or command arguments, and telemetry can be disabled with NIMBUS_TELEMETRY=false.
Nimbus works with standard SFDX project format - the same structure used by Salesforce CLI (sf/sfdx).
Your project root should contain an sfdx-project.json file that defines your package directories. Apex classes go in the standard force-app/main/default/classes/ path (or whatever your sfdx-project.json specifies).
Run nimbus init at your project root to initialize the local environment. Nimbus reads your sfdx-project.json to locate your Apex source files automatically - no additional configuration needed.
Yes - and this is increasingly one of the most important use cases. AI coding tools like Claude Code, Cursor, and GitHub Copilot work in write-test-fix loops. They generate code, run tests, read failures, and iterate. That loop only works when test execution is fast and local.
With org-based testing, an AI agent would need to deploy to a scratch org and wait 5-10 minutes per iteration - making the agent effectively useless for Apex. With Nimbus, the agent runs nimbus test, gets results in milliseconds, and can iterate at the same speed it does for Python, TypeScript, or any other language.
Nimbus makes Salesforce development compatible with the agentic workflows that are becoming standard everywhere else. Your AI assistant can write a trigger, test it, fix it, and verify - all without touching an org.
Yes. Headless 360's custom MCP servers wrap existing Apex hooks - @InvocableMethod, @AuraEnabled, @RestResource, and autolaunched Flows - which Nimbus has executed locally since day one. The MCP wrapping is metadata configuration, not new Apex code, so your custom MCP servers test against the embedded Postgres with no extra setup.
On top of that, Nimbus itself ships an MCP server (nimbus mcp) that registers alongside the Salesforce DX MCP server, so AI agents can call local test execution and live-org tools in the same loop.
The full breakdown - including which standard servers map to what, and what's not yet covered - is on the dedicated Headless 360 page.
Still have questions?
Reach out to us at support@testnimbus.dev and we'll get back to you.
Available today.
Install Nimbus in one line and run your first Salesforce Apex test in minutes.