Nimbus was renamed renmy runtime in October 2026. Same tool, same binary; the record of the rename has the details.
Short version. renmy runtime is a local Salesforce Apex runtime and developer toolchain. It executes real Apex, SOQL, DML and Salesforce Flows on your machine against an embedded PostgreSQL, so an Apex test finishes in tens of milliseconds instead of after an org round trip. Around that runtime sit a language server, a live debugger, line and branch coverage, mutation testing, a browser Dev UI, an MCP server for AI agents, and a gated path to production through renmy deploy and renmy release. It is one binary for macOS, Linux and Windows, with no org, no scratch org, no Docker and no JVM. The Free tier covers unlimited local test runs and gated deploys; Pro and Team are free during the public beta.
Who this is for
You have heard the name Nimbus or renmy, you write Salesforce Apex or maintain the pipeline that deploys it, and you want the whole toolchain in one read rather than twelve product pages. If the idea of a local runtime is new to you, What a local runtime is, and why Salesforce never gave you one starts from zero. This article assumes you have the idea and want the inventory.
What is renmy runtime?
Every other ecosystem gives a developer a runtime on their own machine. A Java developer presses "run test" and the JVM on their laptop answers in about a second; a JavaScript developer types npm test and Node answers. Salesforce never shipped that for Apex. The compiler, the database and the test runner live in Salesforce's data centres, so the only way to learn whether a class works has been to deploy it to an org, wait, and read the result.
renmy runtime is the missing piece. It is an interpreter for Salesforce Apex that runs on your machine, backed by an embedded PostgreSQL that stands in for the org's database, and it enforces the platform's rules: governor limits, order of execution with triggers and flows, Test.startTest and Test.stopTest, @testSetup, per-test transaction isolation, the Stub API. It is not a mock library and not a transpiler to Java. It executes your source tree as written.
Two numbers frame what that buys. A typical Apex test completes in tens of milliseconds, SOQL and DML included. In the published benchmark, four open-source Apex suites with 837 tests took about 1 min 46 s to deploy and run in a Salesforce org and 2.4 s locally, roughly 45 times faster, with every test passing in both places. The method and numbers are public, and so is the parity record that lists what matches the platform and what does not.
The rest of this article is a tour in six stops: run, edit, test, debug, integrate, ship. Each stop has one command block. Everything is free unless marked Pro, and Pro is free during the public beta.
How does renmy runtime run Apex without an org?
Install one binary, step into an SFDX project, run the tests.
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 "*" # every test in the project
renmy test InvoiceServiceTest # one class
renmy test InvoiceServiceTest.bulk # one method
renmy exec -c "System.debug([SELECT COUNT() FROM Account]);" # anonymous Apex, local database
renmy validate # compile and type-check, run nothing
Under renmy test, classes, interfaces, enums, generics and triggers execute as Apex; SOQL is translated and run against PostgreSQL; DML fires the triggers on the object and the record-triggered flows on it, in the platform's order. Autolaunched, record-triggered and screen flows run from their metadata, so a Salesforce Flow and the trigger that shares its object are tested together, which is where order-of-execution bugs live. Flows and governor limits each have their own page.
Which editors does renmy runtime work in?
The runtime ships a language server, and every editor integration is built on it.
# The Apex language server, for any LSP client
renmy lsp
# Or install renmy runtime as a Salesforce CLI plugin
sf plugins install @nimbus-solution/nimbus-sf-plugin
sf nimbus apex run test
Completion, hover, go to definition, rename, diagnostics, code lenses and inlay hints work in VS Code, Cursor, Windsurf, Neovim, Zed, Helix, JetBrains IDEs and Emacs. The VS Code extension is on the Microsoft Marketplace and Open VSX, so it installs in Cursor, Windsurf and VSCodium as well. For IntelliJ IDEA there is Renmy Runtime - Salesforce IDE on the JetBrains Marketplace: run icons in the gutter on every test, a native debug session against the local runtime, Apex and SOQL consoles, and it works in the Community edition. Renmy Runtime for JetBrains walks through it. Both plugins run on the backends the CLI ships; nothing is reimplemented.
What does renmy runtime measure about your tests?
Passing is the lowest bar. The test stop measures whether the tests are any good.
renmy test "*" --coverage # line and branch coverage; HTML, JSON, Cobertura, JUnit XML
renmy coverage diff # what this change did to coverage, for the pull request
renmy fixture # generate a test data factory class from the schema
renmy history --flaky # tests that pass and fail without a code change
renmy test:watch # re-run affected tests on save (Pro)
Coverage is measured for lines and branches; the org reports lines only. Reports come out as HTML, JSON, Cobertura XML and JUnit XML, and a --min-coverage gate fails a deploy or release below the bar. Mutation testing (Pro) goes further than coverage can: it changes your code in small ways and checks whether the tests notice. To our knowledge it is the first for Apex. renmy fixture reads required fields and lookups from the local schema and writes a test data factory class, and renmy history --flaky finds tests that flip without a code change. Coverage has the formats and flags.
How do you debug Apex with renmy runtime?
renmy explain InvoiceServiceTest.bulk # one failure in full, and what could not be established
renmy triage # a run's failures, grouped by recorded cause
renmy graph # what a change to a class can reach
renmy dev # browser test runner, coverage, schema, Apex REPL
The debugger is live, over the Debug Adapter Protocol. Set a breakpoint in a .cls or .trigger file in VS Code or a JetBrains IDE, run the test, and it stops there with variables per frame, stepping and watches, while the test is running. That is not the same as replaying a debug log afterwards. Recording is free; stepping is Pro.
When you would rather read than step, renmy explain reports one failure with the exception, the source location, expected versus actual and the SOQL and DML just before it, and says what it could not establish. renmy triage groups a whole run's failures by the cause the engine recorded, never by matching message text. renmy graph shows what a change to a class can reach. renmy dev opens the Dev UI in a browser, with a test runner, a coverage explorer, a schema browser and an Apex REPL, no editor required. Structured execution traces are Pro.
How do AI agents and other tools connect to renmy runtime?
# Register the MCP server with Claude Code
claude mcp add nimbus -- renmy mcp
# Or register it with the clients renmy knows
renmy mcp install
# A Salesforce-compatible REST and gRPC Pub/Sub API on localhost (Pro)
renmy serve
Coding agents work in Python and TypeScript because they can write, run and fix in a loop measured in seconds. On Apex they stalled, because the only runtime was an org away. renmy mcp is a Model Context Protocol server with tools such as run_apex_tests, execute_anonymous, get_coverage and explain_failure, so Claude Code, Cursor, Copilot or any MCP client can run and verify Apex on your machine, and the org only sees code that has already passed. The MCP server is part of Pro, free during the beta. Let your AI agent run Apex tests covers the setup and what a session looks like; the agentic coding page has the patterns.
Beyond agents, renmy serve (Pro) exposes a Salesforce-compatible REST and gRPC Pub/Sub API on localhost, and renmy app (Pro) hosts an LWC or Vite UI bundle against the local runtime, so a front end runs offline against real Apex. The daemon (Pro) keeps all of it warm between runs.
How does renmy runtime deploy to Salesforce?
The inner loop proves the code. The org still has to receive it, and renmy runtime owns that path too.
# Gated one-shot deploy: snapshot, local gates, org check-only validation, deploy. Free.
renmy deploy
# Split it: validate now, approve, deploy the validated payload later, with a receipt (Pro)
renmy release validate
renmy release deploy
# Read the org deploy queue, and resubmit a stuck job
renmy release status
renmy release watch
renmy release requeue
# Any Salesforce CLI command, unchanged; and pin the CLI version for CI
renmy sf org list
renmy toolchain sf
renmy deploy snapshots the selected source into a bundle, runs local validation and the configured test and coverage gates against that bundle, validates the identical bytes in the target org with a real Salesforce check-only validation, and only then deploys. It is Free, because the safe default should not sit behind a paywall. renmy release validate and renmy release deploy (Pro) split validation from deployment and write an immutable receipt: bundle digest, git revision, org fingerprint, gate results, the Salesforce validation job id and the quick-deploy expiry. A team can validate on one runner, hold for approval, and quick-deploy the exact validated payload from another machine. renmy release status, watch and requeue read and recover the org's deploy queue. renmy sf <anything> passes any Salesforce CLI command through with arguments, prompts and exit codes intact, and renmy toolchain sf pins the CLI version so CI runners reproduce the toolchain. Deploy and release have the full detail; Salesforce CI without scratch orgs shows the pipeline.
I already have a sandbox. Why would I need this?
Keep the sandbox. It is still where the deploy lands, where a user clicks through a Lightning page and where an integration is checked end to end. What a sandbox is bad at is the hundred small edits before that: each one costs a deploy, a wait and a log, and a shared sandbox runs everyone else's automation alongside yours. renmy runtime takes that loop off the org. You edit, the test answers in milliseconds, and when the class is right, renmy deploy validates the same bytes in the sandbox or in production before anything lands. Org-shaped work stays in orgs; code-shaped work moves to your machine. A scratch org has the same shape, with an expiry date added; the scratch org tax prices it.
What is free and what is Pro?
Free, for individual developers, $0 and no card: unlimited local test runs, gated deploys with renmy deploy, Salesforce CLI pass-through and the IDE integrations, on one machine. Pro adds the daemon, renmy serve, parallel runs, watch mode, debugger stepping, mutation testing and the MCP server, on three machines. Team adds CI runs, a CI runner licence, the on-prem assurance console and seats. Pro and Team are free during the public beta; the list prices are $19 per month and $49 per developer per month. Enterprise starts at $20,000 per year. The pricing section is the current word.
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 "*"
Then the quickstart, the GitHub repository for issues, docs and releases, and for IntelliJ IDEA the JetBrains plugin. Questions go to the Slack.
Frequently asked questions
Is renmy runtime the same thing as Nimbus?
Yes. Nimbus was renamed renmy runtime in October 2026. It is the same tool, the same binary and the same repository line, and the nimbus command, the NIMBUS_* variables, nimbus.properties, ~/.nimbus and the .nimbus/ directory in a project all keep working. The record of the rename is at https://renmy.net/blog/nimbus-is-now-renmy.
Does renmy runtime need a Salesforce org, Docker or a JVM?
No. renmy runtime is one binary for macOS, Linux and Windows. It executes Apex, SOQL, DML and flows against an embedded PostgreSQL on your machine. An org is needed only when you deploy to it or pass a command through to the Salesforce CLI.
Is renmy runtime a mock?
No. It executes real Apex against a real database, with governor limits, order of execution with triggers and flows, Test.startTest and Test.stopTest, @testSetup and per-test transaction isolation enforced. Where it differs from the platform is recorded publicly in the parity record at https://renmy.net/parity.
What does renmy runtime cost?
The Free tier is $0 with no card and covers unlimited local test runs, gated deploys, Salesforce CLI pass-through and the IDE integrations on one machine. Pro and Team are free during the public beta; their list prices are $19 per month and $49 per developer per month. Enterprise starts at $20,000 per year.
Which editors does renmy runtime support?
VS Code, Cursor, Windsurf and VSCodium through the VS Code extension; IntelliJ IDEA and the other JetBrains IDEs through the Renmy Runtime - Salesforce IDE plugin; and Neovim, Zed, Helix and Emacs through the language server, renmy lsp.
Top comments (0)