Nimbus was renamed renmy runtime in October 2026. Same tool, same binary; the record of the rename is here.
Short version. A local Apex runtime is a program that executes Salesforce Apex, SOQL and DML on your own machine, with no Salesforce org involved. A Java developer's tests run on the JVM on their laptop; a Salesforce developer's run in an org, after a deploy. renmy runtime, a local Salesforce Apex runtime runs Apex classes, triggers and Salesforce Flows against an embedded PostgreSQL, enforces governor limits and order of execution, and completes a typical Apex test in tens of milliseconds. It does not replace the org; it replaces the hundred round trips before you deploy to it, and it is free for individual developers.
How developers run tests everywhere except Salesforce
A Java developer saves a file, clicks the run icon beside a test method in IntelliJ IDEA, and the JVM on their laptop compiles and executes it. Green or red in about a second. A JavaScript developer types npm test; a Go developer types go test ./.... In every case the compiler, the runtime and the test runner are programs on the developer's own machine. Nothing is deployed anywhere for code to run.
If you have only ever written Salesforce Apex, you have never done that. Your loop looks like this:
# Save the class, then:
sf project deploy start --source-dir force-app # send the edit to an org, which compiles it
sf apex run test --tests AccountTierServiceTest --wait 10 # queue the test and wait
sf apex get log --number 1 # read what happened
Three round trips to the org to learn whether one assertion holds. The cycle takes a minute or two on a quiet org, longer on a busy one with a shared test queue. The answer comes back as a debug log to read, not a running process to inspect. Most Salesforce developers have never experienced anything else, so it does not register as a cost. Everywhere else in software it would.
Why Salesforce never gave you a local Apex runtime
Apex has only ever run on Salesforce's servers. There is no compiler to download and no runtime to start on a laptop. The language, the database its SOQL reads, the test runner and the governor limits are one system, and it lives in Salesforce's data centers.
The reasons are architectural. Apex is multi-tenant by design: your code shares a server with thousands of other customers, which is why governor limits exist at all. And it is inseparable from the platform's data model, since every insert runs triggers, validation rules, flows and sharing in a fixed order of execution. Everything a Salesforce developer finds slow about Apex follows from that:
- Every edit costs a round trip. Nothing compiles until it reaches an org.
- Feedback arrives in minutes, not milliseconds. The published benchmark ran four open-source Apex suites, 837 tests, in about 1 min 46 s in a Salesforce org (deploy plus run) and in 2.4 s locally, roughly 45× faster, every test passing in both (method and numbers).
- CI needs an org. A JWT certificate, a Dev Hub, a scratch org pool or a CI sandbox, just to run unit tests.
- An outage stops development. When the org is unavailable, nobody can run a test.
- AI coding agents cannot iterate. An agent is good at Python because it runs the tests every few seconds; for Apex, the only runtime was a deploy away.
What a local Apex runtime is
A local Apex runtime is a program on your machine that does what the org does when it runs your code, without the org. It has three parts.
-
An interpreter for Apex. It parses your
.clsand.triggerfiles and executes them: classes, interfaces, enums, generics, triggers. -
A real database. SOQL and DML need somewhere to go. renmy runtime starts an embedded PostgreSQL as a local process and runs your queries and inserts against it.
insert,[SELECT ...], savepoints and rollbacks are real operations on real rows (why PostgreSQL). -
The platform's rules. This is what makes it an Apex runtime rather than an interpreter for a Java-like language. Governor limits are counted and enforced (governor limits). Triggers and flows fire in Salesforce's order of execution.
Test.startTest()andTest.stopTest(),@testSetup, per-test transaction isolation and the Stub API behave as they do in an org. Salesforce Flows (autolaunched, record-triggered and screen) run from their metadata, next to the Apex triggers on the same object (flows).
Take a test class you have written a version of:
@IsTest
private class AccountTierServiceTest {
@IsTest
static void assignsEnterpriseTierAboveThreshold() {
Account acc = new Account(Name = 'Northwind Traders', AnnualRevenue = 5000000);
insert acc;
Test.startTest();
AccountTierService.assignTiers(new Set<Id>{ acc.Id });
Test.stopTest();
acc = [SELECT Tier__c FROM Account WHERE Id = :acc.Id];
Assert.areEqual('Enterprise', acc.Tier__c);
}
}
Run locally, insert acc writes a row to the embedded database and fires every Account trigger and record-triggered flow in your project, with their SOQL and DML counted against the limits. Test.startTest() resets those limits. The query reads the row back from the same database, and when the method ends its transaction is rolled back, so the next test starts clean. The whole thing takes tens of milliseconds, and nothing left your machine. Standard objects are built in; custom objects and fields such as Tier__c are read from the metadata in your project (configuration).
What a local Apex runtime is not
Not a mock. A mocking framework replaces the database with stubs you write by hand so that a unit test can avoid DML. It is a legitimate technique and the opposite of a runtime: the runtime executes the real DML, SOQL and triggers and tells you whether they do what you think (runtime vs mocking).
Not a scratch org. A scratch org is a real Salesforce org, provisioned on demand in Salesforce's cloud. It is still an org: you deploy to it, wait for its test queue and rebuild it when it expires (renmy runtime vs scratch orgs; what the rebuild costs).
Not a transpiler. It does not translate your Apex into Java or JavaScript and run that. The interpreter executes the Apex itself, under Apex semantics.
Not a replacement for the org. Which is the next question.
What stays in the org
Lightning pages, screen flows as a user clicks through them, permission checks, anything a human looks at: those are checked in an org. Integrations need real endpoints and real credentials. And the deploy itself, with Salesforce's own validation of your metadata, happens in the org and nowhere else.
A local runtime narrows what you use the org for; it does not remove it. The hundred edits between "I think this works" and "it works" move to your machine; the deploy and its validation stay in the org. renmy deploy keeps that order explicit: local test and coverage gates, then a real Salesforce check-only validation of the identical bytes in the target org, then the deploy (deploy and release).
I have a sandbox. Why would I need a local runtime?
Because the sandbox is still where you deploy, and the runtime is where you run the hundred edits before that.
A Java team has a staging environment too, and nobody proposes running unit tests only there, after a deploy, in a shared queue. Staging is for integration, UI and a final check close to production. A sandbox plays that role, and a local runtime does not take it away; it takes away the sandbox's second job as the only place your code can execute.
An org also hands you a log rather than a running process, so a sandbox never gave you:
- A debugger that stops a running test at a breakpoint rather than replaying a log (debugger).
- Branch coverage, which the org does not report (coverage).
- Tests on a train, during an outage, or in a CI job with no org credentials (CI/CD).
- A write-run-fix loop fast enough for an AI coding agent (AI and agentic coding).
renmy runtime: a local Apex runtime you can install today
renmy runtime is the local Salesforce Apex runtime described above, and the one I build. One binary for macOS, Linux and Windows; no JVM, no Docker, no org:
curl -fsSL https://renmy.net/install.sh | sh # macOS, Linux
irm https://renmy.net/install.ps1 | iex # Windows PowerShell
cd your-sfdx-project
renmy test "*"
Then narrow it down:
renmy test AccountTierServiceTest # one class
renmy test AccountTierServiceTest.assignsEnterpriseTierAboveThreshold
renmy test "*" --coverage # line and branch coverage
renmy dev # browser Dev UI: runner, coverage, schema, Apex REPL
Before you trust it, two pages: the benchmark publishes its method, and the parity record lists what matches and what does not; it is not a claim of 100 percent.
A toolchain sits on the runtime: coverage with Cobertura and JUnit XML output, mutation testing (Pro), a live debugger in VS Code and JetBrains, renmy explain for failures, an MCP server for Claude Code, Cursor and Copilot, and gated deploys with release receipts. The whole of it is in renmy runtime explained. If you distrust tooling claims on principle, how to evaluate a local Apex runtime before you trust it is the checklist; its first item is to run renmy test "*" on your own repository.
It works from the terminal, from a VS Code extension and from a JetBrains plugin for IntelliJ IDEA Community and Ultimate (Renmy Runtime - Salesforce IDE on the Marketplace). It is free for individual developers, no card; Pro and Team are free during the public beta.
Who this is for
Salesforce developers who write Apex and have only ever run it inside an org: this is the piece of a toolchain every other ecosystem takes for granted. If you came to Salesforce from Java, Kotlin or TypeScript and miss your test runner, coming to Salesforce from Java picks up from here.
Try it
curl -fsSL https://renmy.net/install.sh | sh # macOS, Linux
irm https://renmy.net/install.ps1 | iex # Windows PowerShell
cd your-sfdx-project
renmy test "*"
The quickstart takes it from there. Issues, docs, examples and the released binaries are on GitHub at renmy-solutions/renmy. If you work in IntelliJ IDEA, the plugin is Renmy Runtime - Salesforce IDE.
Frequently asked questions
What is a local Apex runtime?
A local Apex runtime is a program that executes Salesforce Apex, SOQL and DML on a developer's machine instead of in a Salesforce org. It combines an Apex interpreter, a real database and the platform's rules (governor limits, order of execution, test isolation), so tests behave as in an org and complete in milliseconds. renmy runtime, formerly Nimbus, is one: it runs Apex and Salesforce Flows against an embedded PostgreSQL, with no org, no Docker and no JVM.
Is a local Apex runtime the same as a scratch org?
No. A scratch org is a real Salesforce org created on demand in Salesforce's cloud; you still deploy to it, wait for its test queue and rebuild it when it expires. A local Apex runtime runs on your machine with no org at all. Scratch orgs and sandboxes remain the right place for UI work, integrations and the final validation before a deploy.
Does a local Apex runtime replace my sandbox?
No. The sandbox is still where you deploy and where anything a user looks at is checked. The runtime is where you run the many edit-and-test cycles before that deploy; renmy deploy then runs local gates, a real check-only validation in the org, and the deploy, in that order.
How accurate is a local Apex runtime compared with a Salesforce org?
renmy runtime enforces governor limits, runs triggers and flows in Salesforce's order of execution, and supports Test.startTest and Test.stopTest, @testSetup, per-test transaction isolation and the Stub API. It interprets your real Apex against a real database; it is not a mock and not a transpiler. The parity record at renmy.net/parity is public and lists what matches and what does not. In the published benchmark, all 837 tests of four open-source suites passed both locally and in an org.
Does renmy runtime cost anything?
renmy runtime is free for individual developers: unlimited local test runs, gated deploys, Salesforce CLI pass-through and IDE integration on one machine, with no card. The Pro and Team tiers (daemon, watch mode, parallel runs, debugger stepping, mutation testing, CI runs) are free during the public beta; the list prices are $19 per month and $49 per developer per month.
