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 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 - IntelliJ plugin (coming soon) 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:
- Complex sharing rules and field-level security enforcement - @future, @queueable, and Batchable async patterns - Visualforce and Lightning Web Component rendering - Approval processes and workflow rules - Platform events (publishing works, subscription does not) - Some complex SOQL features (TYPEOF, 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."
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, no telemetry is collected, and no cloud service is involved in test execution.
The only network call Nimbus makes is license validation for Pro and Team features, which sends your license key (not your code) to the licensing server. Free tier makes no network calls at all.
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.
Launching soon.
Get notified when Nimbus is available.