DEV Community: René Knierim

Rehearse a Salesforce data load before you load it

René Knierim — Thu, 29 Oct 2026 19:56:57 +0000

Nimbus was renamed renmy runtime in October 2026; the record of the rename is at https://renmy.net/blog/nimbus-is-now-renmy.

Short version. A Salesforce data load is a deploy in disguise: every row runs the org's triggers, validation rules and flows, and you find out what they did after the rows are in. renmy runtime is a local Salesforce Apex runtime that runs the same automation on your own computer, against a small database it brings with it, with no Salesforce org, scratch org or sandbox. The Data Loader in its JetBrains plugin, Renmy Runtime - Salesforce IDE, maps a CSV onto an object, and Simulate runs every row through those triggers, flows and validation rules in a transaction that is rolled back, so you see which rows would be refused, and why, before any reach the org. Upload to Org then sends the same file to the org you pick. The real load still happens in the org; the rehearsal is local, free and repeats in seconds.

Why a Salesforce data load is a deploy

Picture the file: 5,000 invoices from the old system, cleaned up in a spreadsheet, saved as a CSV. You map the columns, press go and watch the counter. When it stops, the error file holds 300 rows the org refused, and each of the 4,700 it accepted fired a flow that created a task nobody wanted.

Nothing went wrong with the tool. A data load does what a user does when they save a record, five thousand times, without pausing. For every row the org runs the automation built up over the years, in a fixed order: before-save flows, before triggers, validation rules, duplicate rules, the save, after triggers, assignment rules, workflow rules, processes and after-save flows. The row that fails comes back as a line in an error file. The row that passed but did something you did not intend is harder to find, because nothing reported it.

A developer who changes a trigger gets a validation step before the change reaches production. A data load has never had one: the first time your file meets the org's automation is the real run.

Who this is for: admins who load and update data, migration leads moving or consolidating orgs, and anyone who has opened an error CSV after a load and wished they had seen it first. No terminal, no code. IntelliJ IDEA Community is free, and the plugin installs the runtime for you.

What a local runtime is, in plain words

Apex, triggers, validation rules and flows run inside Salesforce, on Salesforce's servers. That is why every change is deployed and every test waits for the org. A local runtime is a copy of that engine that runs on your own computer instead.

renmy runtime is one. It executes real Apex (classes and triggers), SOQL, DML and Salesforce Flows (record-triggered, autolaunched and screen flows) against an embedded PostgreSQL, a small database that ships inside the program that you never install or manage. No Salesforce org, no scratch org, no sandbox, no Docker, no JVM: one program for macOS, Linux and Windows. A Java or JavaScript developer who presses "run test" has always had this; Salesforce developers ran Apex tests in an org and waited. What is a local Apex runtime? explains the idea from zero.

It is not a mock or a guess. Governor limits are enforced. Triggers and flows fire in the platform's documented order of execution, and a flow fault arrives as the error Salesforce would raise: FIELD_CUSTOM_VALIDATION_EXCEPTION for a Custom Error element, CANNOT_EXECUTE_FLOW_TRIGGER for anything else (https://renmy.net/flows). Where the runtime matches the platform and where it does not is a public record at https://renmy.net/parity; read it rather than trusting any claim of a perfect match.

How to rehearse a data load in IntelliJ IDEA

1. Install the plugin and open the project

In IntelliJ IDEA, open Settings → Plugins → Marketplace and install Renmy Runtime - Salesforce IDE (https://plugins.jetbrains.com/plugin/32360-renmy-runtime--salesforce-ide, version 1.15.1). IntelliJ IDEA Community, which is free, is enough. The Marketplace installs the one dependency, LSP4IJ; no JDK of your own is needed.

Then open your Salesforce DX project: the folder with an sfdx-project.json that your developers keep in version control. Ask them for a checkout; it holds the triggers, flows and validation rules the rehearsal will run. On first open the plugin installs the runtime into ~/.renmy/bin and starts it. The Free tier needs no account.

If the org has automation the project does not, the rehearsal cannot run it. Drift, in the Org workspace, marks every file as in sync, differs, org only or local only, and Retrieve from Org fetches what the project lacks. Anything that talks to an org needs the Salesforce CLI; Authorize New Org… runs its browser login.

2. Put the file on the Data Loader

Open the Org workspace and its Data Loader tab. Drop the CSV on it, choose a file, paste rows, or right-click a file in the Project view and pick Use in Data Loader. Choose the operation: insert, update, upsert or delete.

The object is read from the Id prefix of the key column and the columns are mapped onto fields. A cell that cannot be read lands in the Problems table before anything else happens. For invoices-q3.csv, set to update:

Id → Id, the key column; the prefix a0B identifies Invoice__c.
Amount → Net_Total__c, matched by field label.
Status → Status__c, matched by API name; a picklist with 4 values.
Due → Due_Date__c, matched by label, with a note: 3 cells are not a date.

Three bad dates are visible before anything has run.

3. Press Simulate

Simulate runs every row through the local runtime in batches of 200, inside a transaction that is rolled back. The triggers, flows and validation rules in the project fire for each row, as the org's would. The report says what would change and which rows would be refused, and why:

Simulate      200 rows · 1 batch · rolled back
197           would update
  3           refused by validation rule Amount_Positive:
              "Net total must be greater than zero"

Predicted Changes…   Problems…   Retry Failed Rows

Predicted Changes lists what would change on each row, including what a before-save flow or a trigger writes on the way; Problems lists the refused rows with the platform's own message. The local database is left as it was.

4. Fix the file and simulate again

Three invoices have a negative net total. Fix them in the spreadsheet, save, drop the file again, press Simulate. Each pass takes seconds, and the org has not been touched. Repeat until the report says zero refused and Predicted Changes shows what you meant.

5. Upload to Org

Upload to Org sends the same file to the org you pick. The confirmation names the org and the row count, progress streams per batch, and the rows the org rejected can be exported and retried after you fix them. Anything in the plugin that writes to an org asks first and names the org.

What the rehearsal catches, and what it does not

It catches cells that cannot be read as the field's type, validation rules with the message the user would have seen, triggers that throw, what triggers and before-save flows would write onto each row, and flow faults as the error the platform raises. It does not catch what is not on your machine: automation that exists only in the org is invisible until you retrieve it. For an update or upsert, the rows the file points at should exist locally too; Clone Org Data in the Workbench copies a slice of the org down for exactly that.

This is the honest boundary. The rehearsal is local; the load goes to the org, and the org is the final authority. What it removes is every refusal the project's own automation would have produced, seen on your machine first.

The Workbench: editing rows with the automation switched on

The Data Loader is for files. The Workbench, in the Develop workspace, shows the local database one object at a time, in a grid, with a SOQL box above it. Editing a cell here is not a database update behind the automation's back. renmy runtime runs it as Apex DML on the same interpreter a test uses, so triggers fire, before-save flows run, and a validation rule refuses here what it would refuse in the org, with the platform's own message:

refused   INV-004209 · Net_Total__c · FIELD_CUSTOM_VALIDATION_EXCEPTION:
          Net total must be greater than zero (Amount_Positive)
          the row is unchanged · 1 DML statement · InvoiceTrigger before update

That makes the Workbench the place to try one awkward record before you build a file of five thousand. Data from switches the grid to an org for reading, Pull into Local copies the selected rows down, and the Branch control keeps separate copies of the local data for separate pieces of work. Save as Fixture writes the rows in view as an @IsTest data class, which is the hand-off to your developers: the records you found awkward become the records their tests use. Apex test data factories explains what they do with it.

I already have a sandbox. Why rehearse locally?

Because a load into a sandbox is still a load, and if the result is wrong, undoing it is another load. The sandbox is shared, its data is whatever the last refresh and the last colleague left there, and a refresh is not something you do between two attempts at a file.

The rehearsal rolls back. Each pass takes seconds, and nothing leaves your machine unless you point a panel at an org; source, schema and data stay local (https://renmy.net/security). The sandbox keeps the job only it can do: the dress rehearsal with the org's full configuration, integrations and user interface, once the file is clean.

Try it

For an admin the path is the plugin: install Renmy Runtime - Salesforce IDE in IntelliJ IDEA, open the Salesforce DX project, then Org → Data Loader. A developer who wants the same runtime in a shell needs one command:

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 "*"

Plugin: https://plugins.jetbrains.com/plugin/32360-renmy-runtime--salesforce-ide and its product page, https://renmy.net/jetbrains
Quickstart: https://renmy.net/quickstart
GitHub: https://github.com/renmy-solutions/renmy
Slack: https://join.slack.com/t/renmy/shared_invite/zt-3x7fxoo38-AAgO9QHP7if53JPunBxOPQ

Frequently asked questions

Do I need a Salesforce org to simulate a data load?

No. Simulate runs every row through renmy runtime on your own computer, in a transaction that is rolled back; no org is contacted. You need an org, with the Salesforce CLI logged in to it, only for Upload to Org, and the confirmation names that org and the row count before anything is sent.

Do triggers, flows and validation rules really run during the simulation?

Yes. Every row runs through the local runtime in batches of 200, in the documented order of execution: before-save flows, before triggers, validation rules, duplicate rules, the save, after triggers, assignment rules, workflow rules, processes and after-save flows. Only what is in the project folder runs. The parity record at https://renmy.net/parity lists where the runtime matches the platform and where it does not.

Is the Data Loader free?

Yes. The Data Loader with Simulate and Upload to Org, the Workbench, Schema and the SOQL and Apex consoles are in the Free tier of the plugin: $0, no card, no account, one machine. Pro, which adds debugger stepping, watch mode and mutation testing, is free during the public beta and lists at $19 a month afterwards. Pricing is at https://renmy.net/#pricing.

Do I have to be a developer to use this?

No. There is no code to write and no terminal to open. IntelliJ IDEA Community is free, and the plugin installs the runtime the first time you open a Salesforce DX project. You need a checkout of that project from your developers, since it holds the automation the rehearsal runs, and the Salesforce CLI for anything that talks to an org.

What happens to rows the org rejects during the upload?

Progress streams per batch, and the rows the org rejected can be exported and retried once you have fixed them. A row the org refuses after a clean rehearsal usually points at automation the org has and the project does not; Drift marks it and Retrieve from Org fetches it before the next attempt.

Onboarding Salesforce developers: day one, without an org

René Knierim — Thu, 29 Oct 2026 19:55:32 +0000

renmy runtime was called Nimbus until October 2026. Same tool, same binary; the record of the rename is at https://renmy.net/blog/nimbus-is-now-renmy.

Short version. Onboarding a Salesforce developer today means waiting for a sandbox, a user, a permission set and VPN access before the first test can run. renmy runtime, a local Salesforce Apex runtime, executes Apex, SOQL, DML and Salesforce Flows on the developer's machine against an embedded PostgreSQL, so a new hire can clone the repository, install one binary and run the entire Apex test suite on day one, with no org of any kind. The test environment is a renmy.properties file committed to the repository, and the same renmy test "*" runs in CI. Org access still matters for deployment, but it stops being what a new developer waits for.

Who this is for

Team leads and engineering managers who onboard Salesforce developers: permanent hires, contractors, partner teams. You own the checklist that starts with "request sandbox access" and have watched it take a week. For the whole toolchain in one read, start with renmy runtime explained.

What does day one look like for a Salesforce developer today?

The checklist most teams run has the same shape, and none of it is in the new developer's hands:

Request a sandbox, or a seat in the shared one. An admin has to act.
Request a user in it, with the right profile and permission sets. Another admin, another day.
Get on the VPN, authorise the Salesforce CLI.
Push the repository to the sandbox, which already holds somebody else's branch.
Run the first test. Wait for the deploy, wait for the test queue, read the result.

The teams page puts the typical calendar plainly: day one, request org access; day three, an admin provisions a sandbox; day five, the first test run. Then the loop begins: change a class, push it to the org, run the tests, read the result. Four minutes a cycle on a good day.

A Java developer clones the repository, runs mvn test, and has a result before the welcome meeting. A JavaScript developer runs npm install && npm test. Salesforce developers have never had that option: the Apex compiler, the Apex runtime and the database all live inside the org, so the only way to run an Apex test has been to put the code in an org and ask the org to run it. The sandbox request is how a team rents an Apex runtime.

What is a local Apex runtime?

renmy runtime is a local runtime for Salesforce Apex, made by Renmy UG in Berlin. It executes real Apex (classes, interfaces, enums, generics, triggers), SOQL, DML and Salesforce Flows (autolaunched, record-triggered, screen) on the developer's machine against an embedded PostgreSQL. One binary for macOS, Linux and Windows. No Salesforce org, no scratch org, no sandbox, no Docker, no JVM.

It is not a mock framework and not a transpiler. Governor limits are enforced, Test.startTest/Test.stopTest and @testSetup behave as on the platform, every test method runs in its own transaction, and a trigger or a Salesforce Flow fires in its slot in the order of execution. How closely it matches the org is a public record, not a claim: renmy.net/parity. A typical Apex test completes in tens of milliseconds, SOQL and DML included; the published benchmark puts four open-source suites, 837 tests, at about 1 min 46 s in a Salesforce org (deploy and run) against 2.4 s locally, roughly 45× faster (method and numbers).

For onboarding the consequence is simple: the Apex runtime a new developer needs is now a download, like the JVM or Node, and everything else is in the repository.

Day one with a local runtime, in four steps

Step 1: Clone the repository

A standard SFDX project, with the force-app/main/default layout you would push to an org.

git clone git@github.com:your-org/your-salesforce-project.git
cd your-salesforce-project

Step 2: Install renmy runtime

One line, no admin rights. The embedded database ships inside the binary.

# macOS, Linux
curl -fsSL https://renmy.net/install.sh | sh

# Windows PowerShell
irm https://renmy.net/install.ps1 | iex

renmy --version

In IntelliJ IDEA the JetBrains plugin, Renmy Runtime - Salesforce IDE, does this step itself on first open of a Salesforce DX project; the Free tier needs no account (product page). There is also a VS Code extension.

Step 3: Run the doctor

renmy doctor reads the project, validates the layout and lists anything it needs you to set up. On a clean SFDX project it usually reports green.

renmy doctor

Step 4: Run the whole suite

# Everything
renmy test "*"

# One class, one method, a pattern
renmy test "OrderServiceTest"
renmy test "OrderServiceTest.testDiscountApplies"
renmy test "Order*Test.*"

The output mirrors sf apex run test: pass and fail counts, failure messages, stack traces, coverage. No deploy, no queue and no org login anywhere in those four steps.

The test environment is a file in the repository

In an org, the test environment lives in Setup, Custom Settings and org-level metadata, none of it in source control, so it reaches a new developer through a wiki page or a colleague's memory. renmy runtime reads all of it from one properties file that the team lead writes once and commits:

# Writes a documented renmy.properties with every property, its description
# and example profiles. Uncomment what you need and commit the file.
renmy config init

# Later: the effective configuration and where each value came from
renmy config show

What a team commits, trimmed:

# renmy.properties - committed, shared by every developer and by CI

# Org environment defaults
renmy.org.currency=EUR
renmy.org.locale=de_DE
renmy.org.timezone=Europe/Berlin

# Custom setting org defaults, so no test class needs a @testSetup for them
renmy.seed.org-default.TriggerSettings__c=IsEnabled__c=true
renmy.seed.org-default.AppConfig__c=Endpoint__c=https://api.example.com,Retries__c=3

# Governor limits: relaxed locally, strict in CI
renmy.governor.mode=warn
%ci.renmy.governor.mode=strict
%ci.renmy.trace.enabled=false

Three things in that file matter for onboarding. The org defaults mean UserInfo.getDefaultCurrency() and UserInfo.getLocale() return what they return in your org, on every machine. The custom setting seeds mean the feature flags and endpoints your Apex reads through getOrgDefaults() exist before the first test runs, without @testSetup boilerplate. The %ci. profile means CI reads the same file with stricter settings, activated with --profile ci or RENMY_PROFILE=ci. Permission sets load from the .permissionset-meta.xml files already in the repository and System.runAs() works locally. The full reference is on the configuration page.

What the repository does not carry

This is where day one can still stall. renmy runtime works from source. If the suite depends on something the repository does not hold, the local run says so: the doctor output and the failure trace name the missing capability.

Two cases are common. Custom settings nobody seeded: add them to renmy.properties as above. Managed packages: if the Apex calls into a package whose source the org hides, someone who already has org access runs renmy stub pull --org <alias> --namespaces <namespace> once and commits the stubs; the new developer never needs the org for it (managed packages). A multi-currency org needs renmy.org.features=MultiCurrency, because the runtime starts single-currency, like a new org.

The onboarding checklist has become a test of the repository. If a new hire cannot run the suite from a fresh clone, the repository is missing something, and the team finds out before an incident does. Committing the stub or the seed fixes it for everyone who follows.

What a team lead gets out of this

Contractors are productive before their org user exists. Running the suite needs no connected org, no JWT certificate and no sandbox. The org access request still goes in on day one, because deployment and anything a browser touches still need an org, but it is off the critical path. When the contract ends, revoking org access is the whole off-boarding. Nothing is uploaded to Renmy UG; the security page documents it.

No sandbox per person, and no shared one to trample. Several developers sharing one sandbox means a one-line trigger change fails because of someone else's test data. Locally, each test runs in its own transaction on the developer's own machine: no shared state, no queue.

The same command in CI. The onboarding instructions and the pipeline agree because they are the same lines:

# .github/workflows/test.yml
name: Apex Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://renmy.net/install.sh | sh
      - run: renmy test "*" --profile ci --results-xml results.xml --coverage-report cobertura.xml
        env:
          RENMY_LICENSE_KEY: ${{ secrets.RENMY_LICENSE_KEY }}
      - uses: actions/upload-artifact@v4
        with: { name: test-results, path: results.xml }

No connected org, no scratch org pool, no Dev Hub. CI runs read a license key from the portal through the RENMY_LICENSE_KEY secret and are part of the Team tier, free during the public beta. The CI page has the GitLab equivalent.

"I already give every new developer a sandbox. Why change?"

Keep giving them one. A sandbox is the right place for Lightning pages, for clicking through a flow and for the deployment itself. What it is not good at is being provisioned in minutes by the person who needs it. A sandbox is provisioned by somebody else, on their timeline. A local runtime is provisioned by git clone. And most of an Apex developer's day is the save-run-read cycle, which uses the org as a test runner and nothing else. The scratch org tax prices the same split for scratch orgs.

What does it cost?

Running locally is the Free tier: $0 per developer, no card, unlimited local test runs, gated deploys with renmy deploy, Salesforce CLI pass-through and IDE integration, on one machine. A contractor installs it on their own laptop and pays nothing. Team adds test runs on CI runners, a licence management portal to assign and revoke seats, and a dedicated CI runner licence; it is free during the public beta, with a list price of $49 per developer per month. The teams page has a calculator with a row for developers waiting for org access.

A day-one checklist for the team lead

Run renmy config init once, fill in the org defaults and custom setting seeds, commit renmy.properties.
If the code calls managed packages, pull the stubs once with org access and commit them.
Put clone, install, renmy doctor and renmy test "*" at the top of the README.
Add the same renmy test "*" to CI with the ci profile.
Still request org access on day one. It is for deployment now, not what the first week waits on.

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 is at https://renmy.net/quickstart. Source, issues, docs and released binaries: https://github.com/renmy-solutions/renmy. The JetBrains plugin: https://plugins.jetbrains.com/plugin/32360-renmy-runtime--salesforce-ide. The VS Code extension: https://renmy.net/vscode. Questions go to the Slack.

Frequently asked questions

Can a new Salesforce developer run Apex tests with no org access at all?

Yes. renmy runtime executes Apex, SOQL, DML and Salesforce Flows on the developer's machine against an embedded PostgreSQL, so a fresh clone of a standard SFDX project plus one installed binary runs the entire Apex test suite. No sandbox, scratch org or VPN is involved. Org access is needed later, for deployment and for anything that happens in a browser.

What does renmy config init write, and should the file be committed?

It writes a documented renmy.properties file listing every available property with its description and example profiles. The team lead uncomments what the project needs, such as org defaults, custom setting seeds and a stricter ci profile, and commits the file. Every developer and the CI runner then share the same test environment. A project set up before v1.50.0 may have a nimbus.properties file instead; it keeps working.

What happens when the suite depends on something that is not in the repository?

The local run tells you. The doctor output and the failure trace name the missing capability, so a failing test on day one points at a concrete gap: a custom setting that needs a seed in renmy.properties, or a managed package that needs stubs pulled once with renmy stub pull and committed. Closing the gap in the repository fixes it for everyone who follows.

Does every developer on the team need a licence?

No. The Free tier covers an individual developer on one machine with unlimited local test runs and gated deploys, at no cost and with no card. The Team tier adds test runs on CI runners and a licence management portal for assigning and revoking seats; it is free during the public beta, and the list price is $49 per developer per month.

Does a local runtime replace the sandbox for new developers?

No. Final validation and deployment happen in Salesforce, and anything a browser or an external system needs still happens in an org. The local runtime removes the org from the one step where it only slowed the new developer down: running the Apex tests. Request the sandbox on day one as before.

Where does the Apex go? A security review of a local runtime

René Knierim — Thu, 29 Oct 2026 08:14:35 +0000

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, made by Renmy UG in Berlin: it executes Apex, SOQL, DML and Salesforce Flows on the developer's machine against an embedded PostgreSQL, with no org, no Docker and no JVM. This is the security review for the vendor questionnaire. Apex source is read locally and transmitted to nobody; test data lives in an in-process database with no network port and is rolled back after each test. The Free tier needs no network access at all, telemetry is one activation event that a single setting turns off, and a Pro or Team licence check sends the licence key and a machine fingerprint, never code. The Salesforce org stays the system of record and the deployment target.

What is a local Apex runtime, and why does it need a review?

A Java developer who presses "run test" runs the code on the JVM on their own laptop. Salesforce developers have never had that choice: Apex executes only inside a Salesforce org, so every test run is a deploy into Salesforce's data centres, a queue and a log. A local Apex runtime closes that gap. renmy runtime is an interpreter for the Apex language, an embedded PostgreSQL for SOQL and DML, and the platform's rules (governor limits, triggers, order of execution, per-test transaction isolation) enforced on the developer's machine. It is not a mock; the record of what it runs and what it does not is public at renmy.net/parity.

A compiler does not get a questionnaire. A tool that reads Apex source and builds a database from the project's metadata does, and it should. Three questions cover almost every row of the form: where does the code go, where does the data live, and what leaves the machine. The answers below come from the published security page and the teams page and go no further than those two pages.

Who this is for

Security teams, procurement and enterprise architects who have been handed a request for renmy runtime and need the answers in the order the questionnaire asks them. Developers making that request can start with what a local Apex runtime is and how to evaluate one.

Where does the Apex source go?

Nowhere. renmy runtime reads the project's .cls, .trigger and .flow-meta.xml files from the working tree and executes them in an interpreter that runs as a subprocess on the same machine. No source is transmitted to Renmy UG, to Salesforce or to any third party, and no code is sent to a remote execution environment.

The schema the tests run against comes from the same place. Object definitions are read from sfdx-project.json and the project's .object-meta.xml files; a test run fetches no schema from a Salesforce org. One consequence belongs on the form: running the suite needs no connected org, no JWT certificate and no sandbox. Org access is used for validation and deployment, through the Salesforce CLI the team already trusts, and for nothing else.

For a team that has treated a sandbox per developer as the price of running tests, this is a reduction, not an addition: a developer or a CI runner whose only job is to run the tests holds no credential to any org.

Where does test data live?

In an embedded PostgreSQL on the local disk. Records inserted during a test go into that database and nowhere else. Three properties belong on the questionnaire as written:

It runs in-process. There is no database server to install or operate separately; the engine is embedded in the renmy binary.
It has no network port open. Nothing listens for another host, so there is nothing for a network scan to find.
Nothing persists between test runs. Each test runs in its own transaction, rolled back when the test ends.

Because a test run needs no connected org, the rows in that database are the ones the tests insert. "Does the tool copy production data onto developer laptops?" has a short answer: a test run has no org to copy from.

What leaves the machine?

Case by case, as the security page states it. The RENMY_ prefix on the variables below is the product's former name, kept so existing configuration keeps working.

The Free tier needs no network access

The Free tier requires no network access at all: there is no licence to validate and no account to sign in to. What the runtime can send, on any tier, follows; the complete table, including the update check and the Dev UI, is further down.

Telemetry: one activation event

By default renmy runtime records one privacy-minimal activation event. It goes to Supabase, hosted in the EU, and is used only to measure which installation channels work; it is not sold, shared or used for advertising. The published list of what it never contains is the useful part for the form: no source code, file paths, test names, record data, repository, branch, workflow or command arguments.

Ordinary first-run telemetry is excluded from CI. After a Pro licence validates in headless CI, the runtime records one de-duplicated activation per licence fingerprint, CI provider and installation source, so repeated builds do not inflate installation counts. The same opt-out settings disable that event too.

Licence validation: the key and a machine fingerprint

Pro and Team licences are validated with the licensing API, Keygen, on activation and at most once a day after that. A validation sends the licence key. Activating a machine with renmy login sends more, and the security page lists it: a one-way hash of a random installation ID, the hostname, the machine's display name (on macOS, the Computer Name), the OS and architecture, the number of CPU cores, and your account ID, to enforce seat limits and list your machines in the portal. Nothing from your code, tests or org is sent.

# Sign in via browser and activate this machine
renmy login

# What's sent to the licensing API (Keygen):
# {
#   "key": "RENMY-XXXX-XXXX-XXXX",
#   "machine": "3f9c…"
# }
# key: handed to the CLI by your signed-in browser
# machine: one-way hash of a random installation ID
# On activation also: hostname, display name, OS/arch,
# CPU cores and your account ID

# What's NOT sent:
# - File paths, project names, or source code
# - Test output, coverage data, or Salesforce data
# - Anything from your codebase or org

How do I turn telemetry off?

One line, in whichever form fits the environment:

# Disable telemetry permanently: add this line to
# renmy.properties (in the project or ~/.nimbus/)
renmy.telemetry=false

# Or per shell or CI job
export RENMY_TELEMETRY=false

# RENMY_NO_TELEMETRY=1 and RENMY_NO_TRACKING=1
# are honoured as well

Every one of these also disables the CI activation event. A build server with RENMY_TELEMETRY=false in its job variables makes no call other than the licence validation while it runs the tests.

Does it work offline, and can it be installed air-gapped?

Offline operation

The Free tier needs no network at all. For Pro and Team, the licence is cached locally and validated offline for up to 7 days, so a developer behind a strict proxy or without a connection keeps working for a week without the licensing API answering.

Air-gapped install

renmy runtime supports fully air-gapped installation. The PostgreSQL engine is embedded in the binary, so nothing is downloaded; the binary can be distributed through an internal artifact repository without internet access and copied into place.

# Air-gapped install: copy the binary directly.
# The PostgreSQL engine is embedded in it,
# so nothing is downloaded.
cp renmy /usr/local/bin/renmy

# Turn off telemetry (or renmy.telemetry=false)
export RENMY_TELEMETRY=false
# and the daily update check
export RENMY_NO_UPGRADE_CHECK=1

On-premise licence validation for Enterprise

A 7-day cache is not a licensing model for a network that never connects. For Enterprise customers, on-premise licence validation is available on request, so no outbound network is required for licence checks. Enterprise starts at $20,000 per year on a custom contract.

Network access, command by command

The full table from the security page, reproduced so the questionnaire can quote it:

Command or event	Reaches	Notes
`renmy test`	None	Fully local
`renmy test:watch`	None	Fully local
`renmy dev`	localhost only	WebSocket to the browser on the same machine; `--addr` beyond loopback requires a token
`renmy login`	portal + licensing API	Browser handshake to fetch your key, then the key and the machine details above to Keygen
Licence check (Pro, Team)	licensing API (Keygen)	At most once a day; Pro and Team features keep working offline for up to 7 days
`renmy upgrade`	GitHub releases	Binary download. Homebrew and Scoop fetch the same files
Update check	api.github.com	At most once a day, interactive terminals only, never in CI or under agents. Off: `RENMY_NO_UPGRADE_CHECK=1`
Anonymous telemetry	Supabase (EU)	One activation event. Opt-out: `renmy.telemetry=false`

Two rows are absent, and should be absent from the form too: a remote execution environment, because no code is sent to one, and the Salesforce org, because running the tests does not connect to one.

Who is the final authority, the runtime or the org?

The org. Hold the vendor to this; the teams page says it in the vendor's own words: your org stays the deployment target and the system of record; renmy runtime handles the steps that never needed an org. Final validation and deployment happen in Salesforce, and anything a browser or an external system needs still happens in an org.

Local tests are the fast loop; deployment is gated. renmy deploy, in the Free tier, snapshots the payload, runs the local gates, validates the same bytes in the target org with a real check-only Salesforce validation, and only then deploys. renmy release validate and renmy release deploy (Pro) split that into a validation that writes an immutable receipt, a human approval, and a deploy of exactly the validated payload. For auditors, signed release receipts and the on-premise Assurance console record what was validated and what was deployed. Details: deploy and release.

What to attach to the questionnaire

Everything above is documented publicly:

Security & privacy: what runs locally, telemetry, licence validation, the network table, air-gapped installation.
For teams: the security and procurement section, the plans, and the licence management portal (assign and revoke seats, licence a dedicated CI runner, see who has what).
The Data Processing Addendum and the subprocessor list.
The EULA, the terms and the privacy policy.
A mutual NDA on request, yours or ours.

On price: Free for individual developers is $0, no card. Pro and Team are free during the public beta (list prices $19 per month and $49 per developer per month). Enterprise is from $20,000 per year on a custom contract, with a DPA, PO and invoice billing, and SSO (SAML) on request.

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 here. Issues, docs, examples and released binaries: github.com/renmy-solutions/renmy.

Frequently asked questions

Does renmy runtime send Apex source code to Renmy UG or to Salesforce?

No. renmy runtime reads .cls, .trigger and .flow-meta.xml files locally and executes them in an interpreter on the same machine. No source is transmitted to Renmy UG, to Salesforce or to any third party, and no code is sent to a remote execution environment. The schema is parsed from the project's metadata, so a test run fetches nothing from an org.

Can renmy runtime run without internet access?

Yes. The Free tier requires no network access at all. Pro and Team licences are cached locally and validated offline for up to 7 days. Air-gapped installation is supported, since the PostgreSQL engine is embedded in the binary, and Enterprise customers can have on-premise licence validation with no outbound network.

What does renmy runtime's telemetry contain, and how do I turn it off?

One privacy-minimal activation event, sent to Supabase in the EU and used only to measure which installation channels work. It never contains source code, file paths, test names, record data, repository, branch, workflow or command arguments. Set renmy.telemetry=false in the settings file or export RENMY_TELEMETRY=false; either also disables the separate CI activation event.

What does renmy login send to the licensing API?

The licence key and a one-way hash of a random installation ID, plus, on activation, the hostname, the machine's display name, OS and architecture, CPU core count and your account ID, to enforce seat limits and list your machines in the portal. Pro and Team licences are then validated at most once a day. Nothing from your code, tests or org is sent.

Does a local Apex runtime replace the Salesforce org as the system of record?

No. The org stays the deployment target and the system of record. renmy runtime runs the tests locally, then validates the same bytes in the org with a real check-only validation before deploying; final validation and deployment happen in Salesforce. The parity record of what runs locally is public at https://renmy.net/parity.

Test Salesforce Flows locally before you activate them

René Knierim — Wed, 28 Oct 2026 20:31:07 +0000

renmy runtime was called Nimbus until October 2026. Same tool, same binary, new name; the record of the rename has the details.

Short version. renmy runtime is a local Salesforce Apex runtime: a program on your own computer that executes Apex, SOQL, DML and Salesforce Flows (autolaunched, record-triggered and screen flows) against an embedded database, with no org, sandbox or scratch org involved. A record-triggered flow saved in your project runs locally the moment a test creates or updates the record it watches, together with the Apex triggers on the same object, so an overlap between your flow and somebody's trigger shows up in milliseconds instead of after activation. The simplest path is one command, renmy test "*", run by a developer colleague or by you; the Dev UI, renmy dev, puts the same runner in a browser tab. It executes the logic of a flow; it does not draw the screens of a screen flow. The Free tier covers all of it, with no account and no card.

Who this is for. Salesforce admins, flow builders and low-code consultants who build automation in Flow Builder, test it by clicking through a sandbox, and have never typed a command into a terminal. Every command below is explained before it appears. The developer side of the idea is in What a local runtime is, and why Salesforce never gave you one.

Why testing a Salesforce Flow in a sandbox is slow and risky

The way most flows get tested today: build the flow in a sandbox, press Debug, create a record by hand, watch what happens, adjust, repeat. For a record-triggered flow you may add Flow Tests in Flow Builder. Then you activate, deploy to production, and watch the first real records go through.

Debug and Flow Tests are useful, and both run in the org. That is where the trouble starts.

The sandbox is shared. Someone else's half-finished flow on Opportunity, a validation rule added on Friday, a trigger a developer is midway through: all of it fires when your record saves. When the result is wrong, you spend the afternoon finding out whose automation did it.
The data is yours to build, every time. An Account, an Opportunity in the right stage, an owner with the right profile. You click them together, and after the next sandbox refresh they are gone.
Order of execution is invisible until it bites. Salesforce runs before-save flows, then Apex triggers, then after-save flows, in a fixed order you cannot see in Flow Builder. A flow and a trigger that both create a follow-up Task produce two Tasks, and nobody notices until a sales rep asks why.
Every round takes minutes. Save, activate, find the record, edit it, open the related list, read, reset the data. Twenty rounds is an afternoon.

None of this is a flaw in your flow. It is what happens when the only place that can run a flow is a shared org.

What "on your machine" means when you build flows

When you click Save in Flow Builder, Salesforce stores your flow as a file: an XML document with every element, decision, formula and assignment in it. Your developers already pull these files down into a project folder on their computers, together with every object, field, trigger and class in the org. That folder is what they keep in version control and deploy from. It is the whole org, as files, on a laptop.

A local runtime is a program that reads those files and executes them right there, with its own small database standing in for the org's. This is how every other software platform works: a Java developer presses "run test" and a program on their machine answers in a second, without talking to a server. Salesforce never shipped this for Apex or for flows, because the Apex compiler, the database and the test runner all live in Salesforce's data centres. renmy runtime is that missing program. For you, the practical picture is a private, instant sandbox on one computer, with no other users, that starts empty and throws everything away after each test.

Two words you will meet below. A terminal is the plain text window developers type commands into: Terminal on a Mac, PowerShell on Windows. You type one line, press Enter, and read what comes back. A test is a few lines of Apex that create a record, do the thing your flow reacts to, and check the result. A developer colleague writes it; you can read it, because it says in plain words what the flow is supposed to do.

What renmy runtime does with a Salesforce Flow

renmy runtime executes the flow as it is saved in the file, against an embedded PostgreSQL database, on the computer where the project folder lives. It runs autolaunched, record-triggered and screen flows, including subflows, formulas and decisions. The Apex triggers on the same object run in the same transaction, in the platform's order of execution, with governor limits enforced. It is the same runner that runs the Apex tests in the project, so flows and triggers are exercised together, by the same test. Not a mock of Salesforce and not a copy of it: a runtime that reproduces its rules.

Concretely: when a test updates the stage of an Opportunity, the before-save flows run, then the Apex triggers, then the after-save flows, and the test reads the records that are left. If your new flow and an existing trigger both create a Task, the test sees two Tasks: the order-of-execution problem from the previous section, found in a fraction of a second, before the flow has touched production or a shared sandbox.

How to test a record-triggered flow before you activate it

The example: a record-triggered flow on Opportunity called Closed Won Follow-Up. After an Opportunity is saved with the stage Closed Won, it creates a Task "Schedule kickoff call" for the owner. The org also has an Apex trigger on Opportunity, written two years ago by someone who has since left.

1. Get the flow into the project folder

Ask your developer to retrieve the flow into the project. On their side it is one Salesforce CLI command, and the result is one file:

sf project retrieve start --metadata Flow:Closed_Won_Follow_Up
# -> force-app/main/default/flows/Closed_Won_Follow_Up.flow-meta.xml

2. Write down what the flow should do, as a test

This is the part a developer writes and you read. The whole test is: make an Opportunity, close it, count the Tasks.

@IsTest
private class ClosedWonFollowUpFlowTest {
    @IsTest
    static void closingAnOpportunityCreatesOneFollowUpTask() {
        Account acct = new Account(Name = 'Harbourlight Ltd');
        insert acct;
        Opportunity opp = new Opportunity(
            Name = 'Harbourlight renewal',
            AccountId = acct.Id,
            StageName = 'Prospecting',
            CloseDate = Date.today().addDays(30)
        );
        insert opp;

        Test.startTest();
        opp.StageName = 'Closed Won';
        update opp;   // the record-triggered flow and the trigger run here
        Test.stopTest();

        List<Task> tasks = [SELECT Subject FROM Task WHERE WhatId = :opp.Id];
        Assert.areEqual(1, tasks.size(), 'Expected exactly one follow-up Task');
        Assert.areEqual('Schedule kickoff call', tasks[0].Subject);
    }
}

Read it top to bottom and it is your acceptance criterion: one Opportunity moved to Closed Won, exactly one Task, with that subject. The records exist only inside the test; nothing is left behind.

3. Run it

In the terminal, inside the project folder:

renmy test ClosedWonFollowUpFlowTest

renmy test means "run tests"; the word after it names which ones. renmy test "*" runs every test in the project (the asterisk means "all"; the quotes stop the terminal from interpreting it). A test like this finishes in tens of milliseconds, SOQL and DML included. The published benchmark puts four open-source suites, 837 tests, at about 1 min 46 s in an org against 2.4 s locally, every test passing in both.

4. Read the result

If the old trigger also creates a Task on Closed Won, the first assertion fails: expected 1, actual 2. You now know, before activation, that the flow and the trigger overlap. The fix is one of two edits: retire the Task logic in the trigger, or add an entry condition to the flow. Edit, save, run again. Each round is a second, not a quarter of an hour, and no shared sandbox was touched.

When the flow is ready, the same test becomes a gate: renmy deploy runs the local gates, your tests among them, before anything reaches the org. It is in the Free tier.

Testing a Salesforce Flow without a terminal

Three other faces sit on the same runtime.

The Dev UI. renmy dev starts a browser-based test runner: a page where you pick a test, click run, and read the result, plus a schema browser and a coverage explorer. One command to start it; everything after is clicking.

VS Code. The VS Code extension puts a run button above every test and shows the result inline.

IntelliJ IDEA. The JetBrains plugin, Renmy Runtime - Salesforce IDE, does the same inside IntelliJ IDEA, Community edition included. The JetBrains plugin also opens a flow as a graph (View Flow), so you can read its elements and decisions beside the test that exercises it.

What it does not do

It executes the logic of a screen flow. It does not render the screens. Decisions, assignments, lookups, record creates and updates in a screen flow run. Nobody clicks through the flow on your laptop; what the user sees (labels, help text, conditional visibility, layout) is checked in a sandbox, with a user.
It is not Salesforce. It reproduces the platform's rules closely enough that the four suites in the benchmark pass identically in both places, but the honest statement is the parity record, not a percentage. If a flow uses something the runtime does not cover yet, that is where you find out.
It does not replace review in a sandbox. Permissions, page layouts, what the sales rep actually sees, user acceptance: still an org, still humans.

Do I still need a sandbox?

Yes. The sandbox is where you activate the flow, where a user clicks through it, where permissions and layouts are checked, where the business signs off. What changes is what happens before that: the twenty rounds of "does the flow do the right thing to the records, with the triggers in the loop" move to a laptop, cost a second each, and leave the sandbox clean for the review it is good at.

Try it

# macOS or Linux: open Terminal, paste the line, press Enter
curl -fsSL https://renmy.net/install.sh | sh

# Windows: open PowerShell, paste the line, press Enter
irm https://renmy.net/install.ps1 | iex

# Go to the project folder (ask your developer for the path), then run every test
cd your-sfdx-project
renmy test "*"

# Or start the browser face
renmy dev

The quickstart walks through the first run in under five minutes. Issues, docs and released binaries are on GitHub; for IntelliJ IDEA, the plugin is Renmy Runtime - Salesforce IDE. The Free tier covers unlimited local test runs on one machine, no account, no card.

Frequently asked questions

Can I test a Salesforce Flow without a sandbox?

Yes, for what the flow does to records. renmy runtime executes autolaunched, record-triggered and screen flows on your own computer against an embedded database, together with the Apex triggers on the same object, so a test can create a record, let the flow react, and check the outcome in milliseconds. A sandbox is still where the flow is activated and where users click through it.

Does renmy runtime show me a screen flow the way a user sees it?

No. It executes the logic of a screen flow: decisions, assignments, lookups and record changes. It does not render the screens, so layout, labels, help text and conditional visibility are checked in a sandbox with a user, not locally.

Do I need to know Apex to test a flow locally?

Not to run one. The test that exercises a flow is a short Apex class that creates a record, changes it and counts the result; a developer colleague writes it and an admin can read it as an acceptance criterion. Running it is one command, renmy test, or one click in the Dev UI, VS Code or IntelliJ IDEA.

Does the flow run in the same order as in Salesforce, with my Apex triggers?

Order of execution with triggers and flows is part of what renmy runtime reproduces: the flow and the Apex triggers on the same object run in one transaction, in the order the platform defines, with governor limits enforced. The parity record at renmy.net/parity lists what matches and what does not.

What does it cost?

Nothing for an individual: the Free tier includes unlimited local test runs, flows included, on one machine, with no account and no card. Pro and Team add watch mode, debugger stepping, the daemon and CI runs, and both are free during the public beta.

Apex test sharding: split one suite across CI jobs

René Knierim — Tue, 27 Oct 2026 14:47:47 +0000

renmy runtime was called Nimbus until October 2026. Same tool, same binary; the record of the rename is at https://renmy.net/blog/nimbus-is-now-renmy.

Short version. Test sharding splits one test suite into M slices and runs each slice in its own CI job at the same time, so a suite that takes twelve minutes on one runner takes roughly three, plus setup, on four. renmy runtime, a local Salesforce Apex runtime made by Renmy UG, executes Apex tests on the CI runner itself against an embedded PostgreSQL with no org, which is what makes sharding possible for Apex at all: renmy test --shard 2/4 runs the second of four slices. A slice is a set of whole test classes, balanced by the durations recorded in .nimbus/test-durations.json, so @testSetup stays correct and the shards finish at about the same time. With --results-xml, each shard's JUnit XML carries a shard="N/M" attribute so a test reporter can merge the files. Running on a CI runner is part of the Team tier, free during the public beta.

Who this is for

DevOps engineers and platform teams whose Apex test suite has outgrown a single CI job: thousands of tests, several packages in one repository, a pull-request queue where the time to a green check is the bottleneck. You should know your way around a GitHub Actions matrix; you do not need to have used a local runtime before. If your suite already finishes in under two minutes on one runner, read the section on when sharding is not worth it first.

What is test sharding?

A suite has N test classes and you have M runners. Sharding assigns every class to exactly one runner, each runner executes its assignment, and the results are merged into one report. Nothing runs twice or is skipped, and the wall-clock time drops to roughly the slowest shard plus setup. It does not make the suite cheaper, since the compute is the same plus M times the setup; it makes the suite shorter, which is what the developer waiting for a pull-request check cares about.

Every other ecosystem does this routinely: a JavaScript team puts jest --shard=1/4 in a matrix, a Python team splits pytest across containers. Two conditions make it work. The tests must be independent of each other, and the runner must be able to execute the tests itself, so that adding runners adds capacity.

Why Apex tests could never be sharded in a Salesforce org

In an org, "run the tests" means: deploy the source, ask the org to run the tests, wait in the org's test queue, download the results. The CI runner's CPU is idle the whole time; the work happens in Salesforce's data centre. The CI page on renmy.net puts the org-based cycle at 12 to 20 minutes per run, 4 to 8 of them the deploy and another 3 to 5 the test run. That second condition is the one Apex failed: adding a runner adds nothing, because it would need a second org, a second deploy and a second place in the same queue. The only lever left was to run fewer tests.

renmy runtime removes the constraint. It is a local runtime for Salesforce Apex: an interpreter that executes Apex classes, interfaces, enums, generics and triggers, SOQL and DML, and Salesforce Flows (autolaunched, record-triggered and screen) against an embedded PostgreSQL, on whatever machine it runs on. One binary for macOS, Linux and Windows; no org, no scratch org, no sandbox, no Docker, no JVM. Governor limits are enforced, Test.startTest/Test.stopTest, @testSetup, per-test transaction isolation and the Stub API behave as they do on the platform. It is not a mock framework and not a transpiler; how closely it matches the org is a public record, renmy.net/parity, and the idea from the beginning is in What is a local Apex runtime?

Once the tests execute on the runner, they are a process like any other and the ordinary CI arithmetic applies. The published benchmark runs four open-source suites, 837 tests, in 2.4 s locally against about 1 min 46 s in an org (method and numbers); for a suite that size one job is plenty, and sharding is for the suites that are not. "I already have a CI sandbox" is the usual objection, and you keep it: it stays where the payload is validated and deployed. What moves to the runner is the part that ran on every push.

How does `renmy test --shard N/M` split the suite?

# Four shards. This runner takes the second one.
renmy test --shard 2/4 --results-xml results-2.xml

Job N runs only its assigned slice of the test classes. Three rules decide what that slice is.

Classes stay whole

All methods of a class stay together on one shard. @testSetup runs once per class, and its records are what every method in that class sees; splitting one class across two shards would mean two setups and a result that can differ from an unsharded run. The unit of distribution is the class, not the method.

Balanced by recorded duration

Test classes are not equal: one has eighty methods and a heavy setup, another has three one-liners, and an even split by count leaves one shard running long after the others. renmy runtime balances classes by recorded test duration, read from .nimbus/test-durations.json, so shards finish in roughly equal time. A project with no duration history yet falls back to an even split by class name.

Every shard reads the same file

Each shard computes the whole assignment on its own and takes its slice, so the partition is only consistent if every shard sees the same durations file. If shard 1 has it and shard 3 does not, they compute different partitions and a class can run twice or not at all. Commit .nimbus/test-durations.json or restore it from a cache in every job; committing is the simplest guarantee, because every shard checks out the same revision.

The GitHub Actions matrix

This is the sharded workflow from the CI/CD page, with fail-fast turned off so that one red shard does not cancel the other three and you see every failure in one pass.

name: Apex tests (sharded)

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]

    steps:
      - uses: actions/checkout@v4

      - name: Install renmy runtime
        run: curl -fsSL https://renmy.net/install.sh | sh

      - name: Run tests (shard ${{ matrix.shard }}/4)
        run: |
          renmy test \
            --shard ${{ matrix.shard }}/4 \
            --results-xml results-${{ matrix.shard }}.xml
        env:
          NIMBUS_LICENSE_KEY: ${{ secrets.NIMBUS_LICENSE_KEY }}
          NIMBUS_PROFILE: ci

      - name: Publish test results
        uses: EnricoMi/publish-unit-test-result-action@v2
        if: always()
        with:
          files: results-${{ matrix.shard }}.xml

strategy.matrix.shard fans the job out into four, and --shard ${{ matrix.shard }}/4 tells the runtime which slice to take. --results-xml results-N.xml gives each shard its own JUnit file, and if: always() publishes a failed shard's results too. NIMBUS_LICENSE_KEY is the only secret in the job: no JWT certificate, no connected app, no Dev Hub. NIMBUS_PROFILE: ci activates the %ci. overrides in your committed renmy.properties.

Merging the results

When --shard is combined with --results-xml, each shard's JUnit XML includes a shard="N/M" attribute, so a reporter that reads several files knows they are slices of one run and can merge them. For one combined report instead of a check per shard, upload each file as an artifact and publish once from a job that waits for the matrix:

      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: results-${{ matrix.shard }}
          path: results-${{ matrix.shard }}.xml

  report:
    needs: test
    if: always()
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          pattern: results-*
          merge-multiple: true
      - uses: EnricoMi/publish-unit-test-result-action@v2
        with:
          files: results-*.xml

Coverage is a separate question: a shard measures coverage only for the tests it ran, so one shard's Cobertura file is a partial picture. Measure a whole-suite number where the whole suite runs in one process. renmy deploy --min-coverage refuses a payload below the floor before the org sees it, and renmy coverage diff reports the line and branch delta for a pull request (renmy.net/coverage).

Cache what the shards share

Every shard starts cold. renmy runtime caches parsed ASTs in .nimbus/cache/, which on a project with hundreds of classes brings startup from several seconds to under a second. Restore it in every shard, and the binary with it:

      - name: Cache renmy runtime
        uses: actions/cache@v4
        with:
          path: |
            ~/.nimbus
            .nimbus/cache
          key: renmy-${{ hashFiles('force-app/**/*.cls', 'force-app/**/*.trigger') }}
          restore-keys: renmy-

      - name: Cache binary
        uses: actions/cache@v4
        with:
          path: /usr/local/bin/renmy
          key: renmy-bin-${{ runner.os }}-v1

When is sharding worth it, and when is it not?

Measure the test step on its own before deciding. The CI page puts a single unsharded job at 30 to 90 seconds in total, install included, and a typical Apex test completes in tens of milliseconds with SOQL and DML. For most projects the suite is not the long pole; the checkout and the install are. Four shards means four checkouts, four installs, four embedded PostgreSQL start-ups and four reporter runs; shard a ninety-second job and you will wait longer.

Three things to try first, all from the CI page:

Parallel workers inside one job. %ci.renmy.test.parallel=4 in renmy.properties runs the suite on four workers within the same process (Pro, free during the beta): parallelism without the per-job overhead.
The cache. .nimbus/cache/ and the binary, as above.
An external PostgreSQL for large schemas. A postgres:16-alpine service container with DATABASE_URL removes the embedded database start-up and costs nothing extra, because it starts in parallel with checkout and install.

Shard when the test step itself, after those three, still runs for several minutes: many thousands of tests, classes with heavy @testSetup, several packages in one repository. Then the run costs the slowest shard plus about a minute of setup, instead of the whole suite.

Two caveats. Sharding does not make a slow test class faster; it hides it. A four-minute class sets a four-minute floor for its shard, and the same recorded durations that balance the shards tell you which classes dominate. And sharding changes which classes run next to each other. Each test runs in its own transaction, so a class's result should not depend on its shard; if it does, you have found an order-dependent test. renmy history --flaky records run conditions for that search, and Flaky Apex tests covers the usual causes.

What running sharded Apex tests in CI costs

Running the suite on a CI runner is part of the Team tier, which includes a CI runner licence with its own machine pool. JUnit XML and Cobertura XML output are Pro features. Pro and Team are both free during the public beta; the list prices are $19 per month and $49 per developer per month. The Free tier, $0 and no card, covers unlimited local test runs on one machine and gated deploys. Pricing: renmy.net/#pricing.

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 you from install to a first green run; the unsharded CI job, for GitLab CI as well as GitHub Actions, is in Apex CI without an org; the sharded workflow is on renmy.net/ci. Issues, docs, examples and the released binaries are at github.com/renmy-solutions/renmy; questions go to the Slack.

Frequently asked questions

Does `--shard` split Apex test classes or test methods?

Classes. All methods of a test class stay together on one shard, so @testSetup runs once for the class and every method sees the same records, exactly as in an unsharded run. Shards are balanced by recorded class duration, not method count, so a class with a heavy setup counts for what it costs.

What happens if `.nimbus/test-durations.json` is missing?

If no shard has the file, renmy runtime falls back to an even split by class name; the run is still correct, just less evenly balanced. If some shards have it and others do not, they compute different partitions and a class can run twice or be skipped, which is why the file should be committed or restored from the same cache key in every job.

How do I merge JUnit XML from sharded Apex test runs?

Pass --results-xml to every shard with its own file name, such as results-2.xml. When --shard is in effect, each file carries a shard="N/M" attribute so a CI aggregator knows the files are slices of one run. Publish per shard with if: always(), or upload the files as artifacts and publish them together from a job that runs after the matrix.

How many shards should an Apex test suite use?

Time the test step alone first. If it is under a minute, use one job and turn on parallel workers with %ci.renmy.test.parallel instead; each extra shard costs a checkout, an install and a database start-up. If the step runs for several minutes, start with four and add shards while the slowest shard is still much longer than the setup.

Let your AI agent run Apex tests: MCP for Salesforce

René Knierim — Sun, 25 Oct 2026 20:56:38 +0000

Nimbus was renamed renmy runtime in October 2026: same tool, same binary. The record of the rename is here.

Short version. AI coding agents are good at Python and TypeScript because they can run what they write and read the result within a second, dozens of times per task. They stall on Salesforce Apex because the only place Apex could run was a Salesforce org, minutes away over the network. renmy runtime is a local Salesforce Apex runtime: it executes real Apex, SOQL, DML and Salesforce Flows on your machine against an embedded PostgreSQL, with no org, no scratch org, no sandbox, no Docker and no JVM. Its renmy mcp command is an MCP server that gives Claude Code, Cursor, GitHub Copilot and any MCP client tools such as run_apex_tests and explain_failure, so the agent gets the same write-run-fix loop it has everywhere else and the org only sees code that has already passed. Deploying stays behind the gates of renmy deploy.

Why coding agents work in TypeScript and stall on Apex

An AI coding agent is a loop: write a change, run something, read what came back, decide what to do next. In a TypeScript or Python project, "run something" means starting a process on the same machine: npm test, pytest, a one-off script. It returns in a second or two with a stack trace the agent can read. An agent goes round that loop twenty or forty times on one task, and what it hands back is code it has watched pass.

Salesforce Apex breaks the loop at "run something". Apex compiles and executes only inside a Salesforce org: the compiler, the database and the test runner live in Salesforce's data centres, not on the developer's machine. To run one test, an agent has to deploy the class to an org, wait, start the test run, poll until it finishes, then fetch and parse a debug log. That is minutes per cycle, and it requires the agent to hold credentials for an org. The published measurement: four open-source Apex suites, 837 tests, about 1 min 46 s in a Salesforce org for deploy and run (method and numbers).

Agents respond in one of two ways, and both are bad. Some stop iterating: they write the class and the test, describe what the test "would" check, and hand back code nobody has run. Others keep going and spend minutes and tokens on every round trip. Either way, the one thing an agent is good at, relentless and cheap verification, is the thing Apex took away from it.

What a local Apex runtime changes

renmy runtime is a local Salesforce Apex runtime and developer toolchain. It executes real Apex (classes, interfaces, enums, generics, triggers), SOQL and DML, and Salesforce Flows (autolaunched, record-triggered, screen) on the developer's machine against an embedded PostgreSQL. No Salesforce org, no scratch org, no sandbox, no Docker, no JVM: one binary for macOS, Linux and Windows. It is not a mock and not a transpiler to Java. Governor limits are enforced; Test.startTest/Test.stopTest, @testSetup, per-test transaction isolation, the Stub API and the order of execution with triggers and flows behave as they do on the platform, and the parity record is public. A typical Apex test completes in tens of milliseconds, SOQL and DML included. The 837-test benchmark above runs in 2.4 s locally, roughly 45 times faster, every test passing in both places.

For a Java developer this is what the JVM on their laptop has always been. For an AI agent it is the missing half of the loop. If a local runtime is a new idea to you, What a local runtime is, and why Salesforce never gave you one explains it from zero, and renmy runtime explained tours the whole toolchain.

What renmy mcp exposes to an agent

The Model Context Protocol (MCP) is how coding agents call tools. A server describes a set of functions with typed inputs; the client, the agent, calls them over JSON-RPC and reads a structured result. renmy mcp is such a server. It runs as a child process of the agent and talks over stdio, so there is no port, no network and no credential. The agent reaches the project on the disk in front of it and nothing else.

The tools are the runtime's own commands with the same engine behind them:

run_apex_tests: run a class, a method or a pattern such as "*" and get the results back as data, not as a log to parse.
explain_failure: one failure in full. The exception, the source location, expected versus actual, the SOQL and DML that ran just before it, and what the engine could not establish. It is the same payload renmy explain prints.
get_coverage: line and branch coverage for the run.
get_execution_trace: the execution trace of a run, what ran and in what order.
execute_anonymous: run a snippet of Apex against the local database, the agent's equivalent of a REPL.
list_test_classes: find out what is already tested before writing more.

The full list is in the CLI reference. The MCP server is a Pro feature, free during the public beta. An agent that can run shell commands, as Claude Code can, gets most of the loop on the Free tier from renmy test and renmy explain; the MCP server returns the same results as structured data instead of terminal output.

How to connect Claude Code, Cursor or Copilot to renmy runtime

Install the runtime

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 "*"

Run that last command yourself once before you hand the project to an agent, so you know the suite runs locally and how long it takes. The quickstart covers the first run in detail.

Register the MCP server

# Registers renmy mcp with the agent clients on this machine
renmy mcp install

# Or in Claude Code directly. The server's registered name is nimbus.
claude mcp add nimbus -- renmy mcp

Cursor reads .cursor/mcp.json in the project. The entry is the same command:

{
  "mcpServers": {
    "nimbus": {
      "command": "renmy",
      "args": ["mcp"]
    }
  }
}

GitHub Copilot's agent mode and any other MCP client take the same stdio command, renmy mcp. The registered name stayed nimbus through the rename, so an agent configured before October 2026 keeps working. The how-to Let AI agents run Apex tests walks through each client and renmy skills, curated agent workflows for common Salesforce tasks.

What an agent session looks like with a local Apex runtime

Say you tell Claude Code: "Invoices over 10,000 get a 5 per cent discount. Add it to InvoiceService with tests." The loop, with the tool calls named:

list_test_classes finds InvoiceServiceTest. The agent reads it and the service.
It writes the method and a test:

@IsTest
static void appliesFivePerCentAboveThreshold() {
    Invoice__c inv = new Invoice__c(Amount__c = 12000);
    insert inv;

    Test.startTest();
    InvoiceService.applyDiscounts(new List<Id>{ inv.Id });
    Test.stopTest();

    inv = [SELECT Discount__c FROM Invoice__c WHERE Id = :inv.Id];
    Assert.areEqual(600, inv.Discount__c);
}

run_apex_tests on InvoiceServiceTest. One failure, in well under a second.
explain_failure on that method. Expected 600, actual 0, and the SOQL and DML before the assertion show that the service queried the invoice but never issued an update: its query filtered on a status the test never set. The agent fixes the filter.
run_apex_tests again. Green. get_coverage for the class shows branch coverage, which flags the untested path at exactly 10,000, so the agent adds a boundary test.
run_apex_tests with "*". The whole suite, in a couple of seconds. A change to InvoiceService that broke a trigger test somewhere else shows up now, not in the org.

Each round is seconds. The agent runs the whole suite after every edit because it costs nothing, a discipline most humans drop by the third iteration. Nothing has touched an org. What you review is a diff and a test run you can reproduce in your own terminal:

renmy test InvoiceServiceTest
renmy explain InvoiceServiceTest.appliesFivePerCentAboveThreshold

Agentforce, Headless 360 and the Apex behind your MCP tools

There is a second MCP in the picture. Salesforce Headless 360 (April 2026) lets a team configure custom MCP servers in Salesforce that wrap existing Apex hooks: @InvocableMethod, @AuraEnabled, @RestResource and autolaunched Flows become tools an Agentforce agent, or an external one, calls in production. Those hooks are ordinary Apex and flow metadata, and renmy runtime already executes all of them locally, so the code behind a Headless 360 tool is tested offline against the embedded PostgreSQL with no extra setup. How renmy runtime fits Headless 360 has the detail.

Where the agent should stop: deploying

A green local run is necessary and not sufficient. The org has permission sets, managed packages, validation rules and other teams' automation that your repository does not contain, and the parity record is public precisely because it is not 100 per cent. So the agent should not deploy on its own, and the tool for that boundary is renmy deploy. It snapshots the payload into a bundle, runs the local 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 in the Free tier. renmy release validate and renmy release deploy (Pro, free during the beta) split the two halves with an immutable receipt (bundle digest, git revision, org fingerprint, gate results, Salesforce validation job id, quick-deploy expiry) so a human can approve between them. Let the agent run the tests; keep the deploy, or at least the approval, in a human's hands. Deploy and Release describe both commands.

What stays in the org does not change: the UI, the integrations, the final validation. The runtime is where the hundred edits before that happen.

Who this is for

Developers using Claude Code, Cursor or GitHub Copilot on a Salesforce codebase who have watched the agent produce Apex it never ran. Teams building Agentforce or Headless 360 tools who want the Apex behind them tested before it reaches an org. AI-tooling leads who need to answer "can our agents work on Salesforce?" with a demonstration rather than a slide.

Try it

curl -fsSL https://renmy.net/install.sh | sh
cd your-sfdx-project
renmy test "*"
renmy mcp install

The quickstart takes five minutes. The AI and agentic coding page has the integration patterns. Issues, docs, examples and released binaries are at github.com/renmy-solutions/renmy; questions go to the Slack.

Frequently asked questions

Does an AI agent need a Salesforce org to run Apex tests with renmy runtime?

No. renmy runtime executes Apex, SOQL, DML and Salesforce Flows on the developer's machine against an embedded PostgreSQL. The renmy mcp server runs as a child process of the agent over stdio, so it needs no org, no credentials, no network and no port. The org is only involved when you deploy.

Which AI coding agents work with renmy mcp?

Any MCP client. Claude Code registers it with claude mcp add nimbus -- renmy mcp, Cursor through its mcp.json, and GitHub Copilot's agent mode and other clients take the same stdio command, renmy mcp. renmy mcp install does the registration for you. The server's registered name is nimbus.

Is renmy mcp free?

The MCP server is part of the Pro tier, which is free during the public beta; the list price after the beta is $19 per month. The Free tier, $0 and no card, includes unlimited local test runs, so an agent that can run shell commands already gets the loop from renmy test and renmy explain.

Should an AI agent deploy Apex to Salesforce?

Not on its own. A local pass is necessary and not sufficient, because the org holds metadata and automation your repository does not. Deploy through renmy deploy, which runs the local gates and then a real check-only validation of the same bytes in the org before deploying, or through renmy release validate and renmy release deploy, which put a human approval and an immutable receipt between validation and deployment.

Is renmy runtime the same as Nimbus?

Yes. Nimbus was renamed renmy runtime in October 2026. It is the same binary from the same repository line; the nimbus command, the NIMBUS_* variables, nimbus.properties and the MCP server's registered name nimbus all keep working. The record of the rename is at renmy.net/blog/nimbus-is-now-renmy.

renmy runtime explained: Apex tests, flows and deploys

René Knierim — Sun, 25 Oct 2026 07:37:10 +0000

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.

Salesforce IDE in IntelliJ IDEA: renmy runtime for JetBrains

René Knierim — Sat, 24 Oct 2026 18:29:17 +0000

Nimbus was renamed renmy runtime in October 2026, and the JetBrains plugin that was listed as "Nimbus - Local Apex Runtime" is the same plugin under its new name; the record of the rename is at https://renmy.net/blog/nimbus-is-now-renmy.

Short version. renmy runtime is a local Salesforce Apex runtime: it executes real Apex, SOQL, DML and Salesforce Flows on your machine against an embedded PostgreSQL, with no Salesforce org, no scratch org, no Docker and no JVM. Its JetBrains plugin, Renmy Runtime - Salesforce IDE (version 1.15.1), puts that runtime inside IntelliJ IDEA Community or Ultimate: a run icon on every Apex test, a native debugger with breakpoints, Apex and SOQL consoles against the local runtime or any org, and one tool window with six workspaces. It installs its own runtime on first open of a Salesforce DX project, the Free tier needs no account, and it coexists with Illuminated Cloud.

What a Java developer expects from an IDE, and what Apex developers never had

Open IntelliJ IDEA on a Java project. A run icon sits in the gutter next to every test; click it and the JVM on your laptop answers in under a second. Set a breakpoint, press Debug, and execution stops on that line with every variable in view. Open a database console, type a query, read the rows. None of this is remarkable; it is what an IDE is for.

Now open a Salesforce DX project in the same IDE. The Apex you write cannot run on your machine, because the compiler, the database and the test runner all live inside a Salesforce org. So the workflow became: save, deploy to a sandbox or scratch org, wait, run the test there, download a debug log, read it. The gutter icon has nowhere to send the test. The breakpoint has nothing to stop.

A local runtime is the missing piece: a program on your machine that executes Apex the way the platform does, SOQL and DML included, against a real database it brings along. That is what renmy runtime is, and the JetBrains plugin wires it into IntelliJ IDEA. What a local runtime is, and why Salesforce never gave you one explains the idea from zero.

Who this is for: Java and Kotlin developers who also touch Salesforce and want their ordinary workflow back; Salesforce developers already in IntelliJ IDEA with Illuminated Cloud; teams standardised on JetBrains who do not want a second editor for one language. Coming to Salesforce from Java: where did my test runner go? is the companion piece.

What is renmy runtime for JetBrains?

The plugin is listed on the JetBrains Marketplace as Renmy Runtime - Salesforce IDE: https://plugins.jetbrains.com/plugin/32360-renmy-runtime--salesforce-ide. The current version is 1.15.1 (October 2026). Before 1.15 the listing was called "Nimbus - Local Apex Runtime" (1.0.x); an installed 1.0.x updates in place. The product page is https://renmy.net/jetbrains.

What it needs:

IntelliJ IDEA Community or Ultimate, or any JetBrains IDE from 2025.3 that ships JCEF.
No JDK of your own, and no Salesforce org for the local loop.
LSP4IJ, which the Marketplace installs for you.

Everything the IDE does runs on the same two backends the CLI ships, renmy lsp for language features and renmy daemon for execution. Nothing is reimplemented in the plugin, so a test that passes in the IDE passes the same way under renmy test in a terminal or in CI.

How to install the Salesforce IDE plugin in IntelliJ IDEA

1. Install from Settings → Plugins

Open Settings → Plugins, search for "Renmy Runtime", install, and restart if the IDE asks. Or open the Marketplace page and press Install.

2. Open a Salesforce DX project

On first open of a project with an sfdx-project.json, the plugin installs its runtime into ~/.nimbus/bin (macOS, Linux and Windows). The Free tier needs no account: no sign-up, no card, one machine.

3. Run a test

Open any @IsTest class. There is a run icon in the gutter. Click it.

If you also want the runtime in a terminal, the CLI is the same binary:

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 tool window: six workspaces

One tool window, six workspaces:

Home: the runtime, project health, your account.
Develop: Apex and SOQL consoles, Schema, Workbench, Events.
Org: Browse, Drift, Logs, Data Loader.
Verify: Tests, Coverage, History, Governor.
Release: deploys and releases.
Admin: Users, Permissions, Tracing, Setup, Limits.

Opening a Salesforce file selects the panel that belongs to it without taking focus; the cursor stays in the editor.

Running Apex tests from the gutter in IntelliJ IDEA

Every @IsTest class and method gets a run icon in the gutter and four code lenses: Run, Debug, Coverage and Trace. Results stream into IntelliJ's own test runner tree. After a run, each method shows its time and its SOQL and DML counts inline, so a method that issued forty queries announces itself before a governor limit does.

@IsTest
private class InvoiceTotalsTest {
    @TestSetup
    static void makeData() {
        insert new Account(Name = 'Local Test Account');
    }

    @IsTest
    static void sumsOpenLines() {
        Account a = [SELECT Id FROM Account LIMIT 1];
        Invoice__c inv = new Invoice__c(Account__c = a.Id, Status__c = 'Open');
        insert inv;
        insert new List<Invoice_Line__c>{
            new Invoice_Line__c(Invoice__c = inv.Id, Amount__c = 40),
            new Invoice_Line__c(Invoice__c = inv.Id, Amount__c = 60)
        };

        Test.startTest();
        Decimal total = InvoiceTotals.openTotal(inv.Id);
        Test.stopTest();

        Assert.areEqual(100, total);
    }
}

Click Run on sumsOpenLines and the test executes on your machine: @TestSetup runs, the DML lands in the embedded PostgreSQL, any triggers on Invoice__c fire in the platform's order of execution, Test.startTest resets the limits, and the result appears in the test tree in tens of milliseconds. Tests can also run in an org from the same place.

Governor limits are enforced; Test.startTest/stopTest, @TestSetup, per-test transaction isolation, the Stub API and the order of execution across triggers and flows behave as on the platform. It is not a mock and not a transpiler. The parity record is public at https://renmy.net/parity; read it before you trust any claim, including this one. The published benchmark at https://renmy.net/benchmarks ran four open-source Apex suites, 837 tests, in about 1 min 46 s in a Salesforce org (deploy and run) and in 2.4 s locally, every test passing in both.

Debugging Apex with breakpoints, not debug logs

Click Debug instead of Run and IntelliJ opens a native debug session against the local runtime. Breakpoints go in .cls and .trigger files. Step over, into and out. Variables per frame, watches, evaluate, break on exceptions. It is the debugger Java developers already know, pointed at Apex, and it stops a running test rather than replaying a log.

Replay adds Step Back, Reverse Continue and a Run Timeline, so a recorded run can be walked backwards to the statement that set the wrong value. Recording is free; stepping is Pro, free during the public beta. Details: https://renmy.net/debugger.

Apex and SOQL consoles: local runtime or any org

The Develop workspace has an Apex console and a SOQL console, both with completion and diagnostics, each running against the local runtime or any org the Salesforce CLI is logged in to.

SELECT Account__r.Name, SUM(Amount__c) total
FROM Invoice_Line__c
WHERE Invoice__r.Status__c = 'Open'
GROUP BY Account__r.Name

Two things an org alone cannot do. "Run and Compare" runs the same code locally and in the org and shows what differs. "Find in All Orgs" runs one query in every org you are logged in to, so "which sandbox has this record" stops being a tour.

Data: Workbench, and a Data Loader that simulates first

Workbench queries and edits local rows, keeps data branches, and clones an org's data into a local copy, so tests and consoles run against realistic records without touching the org.

Data Loader maps a CSV onto an object and simulates the load locally first: triggers and validation rules run against the embedded database and the transaction is rolled back. You see which rows would be rejected before one reaches the org. Then it uploads. Anything that writes to an org asks first and names the org.

Org: Drift, Browse and debug-log replay

Browse an org and retrieve what the project lacks. Drift marks every file as in sync, differs, org only or local only; "Compare with Org" opens a diff, and "Retrieve from Org" refuses to overwrite uncommitted work. Logs reads the org's debug logs and replays them locally, so a failure that only happened in the org is not only a text file. Admin shows users, permissions, trace flags and limits.

Editing: inspections, refactorings and metadata as forms

The language features come from renmy lsp: completion, hover docs, go to definition, find references, rename, diagnostics and inlay hints. On top of that:

Sixteen inspections with quick-fixes: SOQL, DML or callouts in loops, hardcoded Ids, empty catch blocks, seeAllData, tests without assertions, unused locals, and more.
Generate: constructor, getters and setters, implement and override, toString, equals and hashCode.
Refactor: Extract Variable, Extract Constant, Extract Method, Change Signature.
Rename a custom field everywhere: across Apex, SOQL, metadata XML, LWC, Aura and Visualforce.
Nineteen live templates: tm, soqlf, bulkt, trycatch, mapid and others.
Go to Test and Create New Test.

Metadata opens as forms: objects, fields, permission sets, labels, custom metadata, page layouts, Lightning pages and more. sfdx-project.json gets a Form tab beside the text.

Previews (Pro, free during the beta) render React, LWC and Visualforce from your source against the local API server. Visualforce renders 25 of the 77 apex: components; the rest are drawn as labelled placeholders, not faked. Previews need Node 20.19+ or 22.12+. Renmy Learn adds ten replayable workshops inside the editor and a searchable field manual.

Does it work with Illuminated Cloud?

Yes. Illuminated Cloud handles editing and org deployment for many IntelliJ teams; renmy runtime adds the local runtime and test loop beside it. Shortcuts live in the Alt+Shift namespace so nothing collides: Alt+Shift+D deploys, Alt+Shift+U retrieves. When Illuminated Cloud is installed it keeps the Apex file types, and a setting under Tools → Renmy decides. Guide: https://renmy.net/how-to/intellij-illuminated-cloud.

I already have a sandbox. Why would I need this?

The sandbox is still where you deploy, where the UI lives and where integrations are checked. The runtime is where the hundred edits before that happen, each costing a click instead of a deploy and a log. When the code is right, renmy deploy (Free) snapshots the payload, runs the local gates, validates the same bytes in the org with a real check-only validation, and only then deploys. The org sees proven code, less often.

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 "*"

Plugin: https://plugins.jetbrains.com/plugin/32360-renmy-runtime--salesforce-ide
Quickstart: https://renmy.net/quickstart
GitHub (issues, docs, examples, binaries): https://github.com/renmy-solutions/renmy
Slack: https://join.slack.com/t/renmy/shared_invite/zt-3x7fxoo38-AAgO9QHP7if53JPunBxOPQ

Frequently asked questions

Does renmy runtime for JetBrains work in IntelliJ IDEA Community Edition?

Yes. The plugin works in IntelliJ IDEA Community and Ultimate, and in any JetBrains IDE from 2025.3 that ships JCEF. You do not need a JDK of your own. LSP4IJ, which the plugin builds on, is installed for you by the Marketplace.

Do I need a Salesforce org to run Apex tests in IntelliJ IDEA?

Not for the local loop. The plugin installs renmy runtime into ~/.nimbus/bin the first time you open a Salesforce DX project and runs Apex tests against an embedded PostgreSQL on your machine. You need an org for Browse, Drift, running tests in an org, Data Loader uploads and deploys. Anything that writes to an org asks first and names the org.

Does the plugin work alongside Illuminated Cloud?

Yes. The two are complementary. Shortcuts live in the Alt+Shift namespace so nothing collides (Alt+Shift+D deploys, Alt+Shift+U retrieves), and when Illuminated Cloud is installed it keeps the Apex file types, with a setting under Tools → Renmy to decide. The guide is at https://renmy.net/how-to/intellij-illuminated-cloud.

What happened to the Nimbus - Local Apex Runtime plugin?

It is the same plugin. Nimbus was renamed renmy runtime in October 2026, and the JetBrains listing became Renmy Runtime - Salesforce IDE with version 1.15. An installed 1.0.x updates in place.

Is the JetBrains plugin free?

The Free tier is for individual developers: $0, no card, no account, with unlimited local test runs, gated deploys, CLI pass-through and IDE integration on one machine. Pro adds the daemon, parallel runs, watch mode, debugger stepping, mutation testing, previews and the MCP server on three machines; it is free during the public beta, with a list price of $19 a month afterwards. Pricing is at https://renmy.net/#pricing.

What a local Apex runtime is, and why you never had one

René Knierim — Thu, 22 Oct 2026 22:43:55 +0000

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 .cls and .trigger files 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() and Test.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.

Salesforce Down During Dreamforce 2026: How I Kept Shipping Apex Without an Org

René Knierim — Wed, 16 Sep 2026 17:57:11 +0000

Note (October 2026): Nimbus, the tool this article is about, has been renamed renmy runtime. Same tool, same binary, new name; the record of the rename is at renmy.net/blog/nimbus-is-now-renmy. The text below has been updated to use the new name.

On September 16, 2026, Salesforce went down. Globally. On day two of Dreamforce.

While tens of thousands of people in San Francisco were hearing about AIforce, Agentforce, and Headless 360, customers around the world were staring at login errors and spinning loaders. Developers refreshed the Trust status page. Deployments stalled. Standups turned into "is it just me?"

I didn't notice.

By the time a colleague pinged me, I had already written, tested, and refactored all the Apex I planned to finish that day. Not because I got lucky, but because my development loop doesn't need an org to be online.

Here's what happened, what it reveals about how we build on Salesforce, and how to make sure the next outage doesn't stop you.

What happened: the September 16, 2026 Salesforce outage in brief

Based on Salesforce's status updates and press coverage at the time of writing:

~07:50 UTC: The service disruption began, affecting Core Service.
Scope: Hundreds of instances across all regions, including the US, UK, Germany, France, Japan, and India.
Symptoms: Severe delays, intermittent errors, and users unable to log in or access services. Even new support cases were hard to submit.
Cause (preliminary): Salesforce pointed to requests stalling on an internal login service, which exhausted available capacity.
Late morning UTC: A fix was validated and rolled out, but some instances took longer to recover, and some customers reported scheduled jobs not running as expected afterwards.

Check status.salesforce.com for the official root cause analysis once it's published.

The timing couldn't have been worse: the biggest week of the Salesforce year, with the entire ecosystem watching.

The real problem: your Salesforce dev loop has a single point of failure

Look at a typical Apex developer's inner loop:

Write code in VS Code or IntelliJ
Deploy to a scratch org or sandbox
Run tests in the org
Wait
Dig through debug logs, fix, repeat

Only step 1 is local. Your compiler, test runner, and debugger all live in Salesforce's data centers.

On a normal day, that means slow feedback. On a day like September 16, it means zero productivity. And Salesforce outages aren't one-offs. There have been major incidents in 2019, 2021, 2023, and 2025, from faulty permission scripts to DNS changes.

No other ecosystem accepts this. Java developers don't stop coding when Maven Central blips. Go developers don't stop testing when AWS has a regional incident. Local-first development is standard everywhere, except Salesforce.

How to develop and test Apex without a Salesforce org

For the past months I've been building and using renmy runtime, a local toolchain for Apex. It lets you run and test Apex on your machine, like any other language.

Here's what my outage morning actually looked like:

1. Running Apex unit tests locally

No deployment, no test queue. Feedback in seconds instead of minutes.

2. SOQL and DML against a real database

renmy runtime embeds PostgreSQL, so queries and inserts hit a real data layer, not brittle mocks.

3. Testing Platform Events offline

A local Pub/Sub gRPC server means event-driven Apex works without an org.

4. Measuring test quality with mutation testing

Coverage tells you code ran. Mutation testing tells you whether your tests would catch a bug. (More on this below.)

5. Tracing instead of debug logs

OpenTelemetry traces show exactly what executed, without the debug log scavenger hunt.

When the platform came back, the only step left was the deployment.

Why 75% Apex code coverage isn't enough

Salesforce requires 75% coverage to deploy to production. But look at this test:

@IsTest
static void calculatesDiscount() {
    Decimal result = PricingService.applyDiscount(100, 0.2);
    System.assertNotEquals(null, result);
}

It fully covers applyDiscount. It also passes if the method returns 100, 80, or -42.

Mutation testing fixes this blind spot. It deliberately changes your code (flips > to <, swaps constants, deletes statements) and reruns your tests. If nothing fails, a "mutant survived," and you've found a gap.

Running this in an org would take hours. Locally, it's part of the normal loop.

Local-first matters even more in the Agentforce era

This year's Dreamforce was all about agents: Agentforce, Agent Script, Headless 360, MCP, vibe coding. AI is writing more and more Salesforce code.

That raises a question nobody on stage answered: where does AI-generated Apex get verified before it touches a real org?

If every check needs a live org, your AI agents stall during outages just like you do. And letting agents iterate directly against sandboxes is slow and risky.

renmy runtime ships an MCP server, so coding agents like Claude Code can run tests, check mutations, and verify Apex locally. The org becomes the place you deploy proven code, not the place you experiment.

Key takeaways for Salesforce teams

Outages will happen again. Plan for them like any other dependency failure.
Decouple your inner dev loop from platform availability.
Coverage is a deployment gate, not a quality metric. Use mutation testing.
CI pipelines get more reliable when unit tests don't need an org for every run.
AI agents need a safe, local sandbox to verify their code.

FAQ

Was Salesforce down on September 16, 2026?
Yes. Salesforce reported a global service disruption starting around 07:50 UTC, affecting instances across all regions during Dreamforce 2026.

Can you run Apex tests without a Salesforce org?
Yes, with a local toolchain like renmy runtime, which runs Apex, SOQL, DML, and Platform Events on your machine.

How do I keep developing during a Salesforce outage?
Move your write-test-refactor loop local. Only deployment and integration testing truly need the org.

Try it

renmy runtime is available for free for everyone, and Pro features are free during the launch period. If the outage cost you half a day, spend twenty minutes setting up a loop that won't care next time.

👉 renmy.net

How did your team handle the outage? Were you stuck, or did you have a workaround? Tell me in the comments. 👇

Run your Salesforce development without an org. Run it with renmy runtime.

Design Salesforce Like a Distributed System

René Knierim — Mon, 22 Jun 2026 11:06:02 +0000

Distributed systems engineers don't get to reach across service boundaries whenever it's convenient. The network stops them. A microservice that needs data owned by another service can't just query it. It has to ask, wait, and handle failure. That friction is annoying. It's also the thing that enforces discipline: every team knows exactly where its responsibility ends, because the boundary is physical.

Salesforce gives you no such friction. Every object in your org, every Account, every Order, every custom object owned by another team, is one SOQL query away. Any Apex class can read it. Any trigger can write to it. Any Flow can fire on it. There is no network. There is no boundary. Nothing stops one domain from reaching into another's territory, and nothing makes that reach-in visible until something breaks.

That's the core problem this article addresses: how to design a Salesforce org with the discipline distributed systems engineers are forced to have, in an environment that will never force it on you. Platform Events and a principled trigger architecture are the tools. Bounded contexts, facts vs commands, and choreography or orchestration are the concepts. The prize is the same thing distributed systems get from their hard boundaries: teams that can ship independently without breaking each other.

This article is opinionated, grounded in real patterns from a production org, and the goal is that it shifts how you think about who's allowed to touch what, not just how to get work done async.
It is also not an argument that every Salesforce org should adopt a distributed systems pattern. Rather, this is a thought experiment exploring what changes when we analyze Salesforce from a distributed systems lens.

1. What Salesforce doesn't force on you (and why that's dangerous)

In a distributed system, the boundary between services is enforced by physics. Service B cannot read Service A's database directly. If it needs data, it calls an API, subscribes to an event stream, or maintains its own projection. These patterns (APIs, events, read models) didn't emerge from clever design thinking. They emerged because there was literally no other option.

The result is that distributed systems engineers develop a reflex: before touching anything, ask "do I own this?" If the answer is no, the question becomes "what's the sanctioned channel for getting what I need?"

Salesforce developers rarely develop this reflex, because the platform never punishes them for not having it. The consequence plays out slowly. In year one, one team writes a trigger on Contact and it works fine. In year two, three teams have logic in the same trigger handler. In year five, no one team can change the Contact object without coordinating with four others, running a full regression suite, and hoping nothing breaks in production. The org has become a non-distributed monolith: all the coupling of a distributed system with none of the boundaries, and no network to make the coupling visible.

Distributed systems thinking is the antidote. Not the mechanics (you don't need service meshes or gRPC), but the mindset: treat domain boundaries as if they were network boundaries, even though they aren't. Refuse cross-domain reach-ins the same way a service refuses direct database access from a neighbour. Use events as the only sanctioned channel for cross-domain communication.

The difference from the distributed world is that on Salesforce you have one significant advantage: the data is already local. You don't need to copy data across service boundaries, because there are no service boundaries at the database level. Every subscriber can re-query the source data directly. It's a SOQL call away. This changes the shape of event design considerably, as we'll get to in §7.

2. Domain bleed: what coupling without a boundary looks like

Distributed systems literature warns about the "distributed monolith": services so entangled they must deploy together, with all the pain of distribution and none of the independence. In Salesforce, you get a mirror-image problem: a non-distributed monolith. One schema, one automation surface, every team in everyone else's business, and no network boundary to make the coupling visible or enforce a fix.

Domain bleed is when one domain's logic executes inside another domain's territory. In Salesforce it looks like this:

Concrete symptoms, all of which you have seen:

A trigger nobody owns. AccountTrigger (or the one handler class) has commits from five teams. Touching it for a Billing change risks a Sales regression. Code review needs three squads.
Automation firing across domains. A Billing flow triggered by a field change on Opportunity, which Sales owns. Sales refactors a picklist; Billing breaks in production; nobody connected the two.
SOQL reaching three domains deep. A Support class queries Case → Contact → Account → Opportunity → OpportunityLineItem, encoding assumptions about four domains' models. Any of them refactoring breaks the query.
Validation rules encoding someone else's invariants. A rule on Contact enforcing a Marketing constraint that fires for every team that ever inserts a contact, including integration users that know nothing about it.
Shared fields with implicit contracts. A field added "just for Marketing" that automation, reports, and tests across the org now silently depend on.

The result is the same coupling a distributed system avoids by construction. Things that should be independent become one fragile thing, concentrated in a single org with a single deploy. You can't ship one domain without regression-testing the others. There is no slice any team fully owns. Velocity collapses as the org ages, and everyone blames "Salesforce technical debt" when the real diagnosis is missing boundaries.

Here's the critical distinction: the shared database is not the bleed. Co-located data is your advantage, not your problem. Distributed systems would kill for it. The bleed is control flow and ownership crossing boundaries: one domain reaching in to query, fire on, or write to another's objects. A distributed system can't do that because the network stops it. In Salesforce, you have to stop it yourself. Events are how you do it.

3. There are two kinds of event-driven Salesforce, and triggers are one of them

Before Platform Events: Salesforce already had an event-driven primitive that every Apex developer uses every day. Triggers are synchronous events. A record changes; the platform fires a before/after trigger; your code runs. The pattern is event-driven at its core.

The problem is ownership. And this is where the two models diverge sharply.

The trigger ownership problem

When a trigger is owned by everyone, it's owned by nobody. The classic symptom: a single AccountTrigger.cls (or one handler class dispatching to a dozen unrelated features) with commits from Sales, Fulfillment, Finance, and Support teams. The result:

Every team coupling to one file means nobody can deploy safely alone. The trigger becomes a bottleneck: a coordination tax for every change, regardless of which domain is touching it.

The old pattern, a TriggerFactory loading handlers from custom settings metadata, improved things by registering handlers per-object. But the fundamental problem remained: multiple teams could still register multiple handlers for the same object, and the execution order and interactions between them were implicit.

Trigger Actions: single responsibility, metadata-driven composition

A prime example of a trigger frame work that solves this issue at the architecture level is Mitch Spano's Trigger Actions framework. Each action is a focused, single-responsibility class that implements one interface:

// One class, one concern, one owner
public class TA_Order_Placed implements TriggerAction.AfterInsert {
    public void afterInsert(List<SObject> triggerNew) {
        // only Fulfillment domain logic here
    }
}

Actions are composed via metadata (Trigger_Action__mdt), not code. The trigger file itself becomes trivial, a one-liner that hands off to the framework:

trigger OrderTrigger on Order (after insert, after update, after delete) {
    new MetadataTriggerHandler().run();
}

What this buys you:

	Legacy `TriggerFactory`	Trigger Actions
Ownership	Multiple handlers, shared registration	One class per concern, clear owner
Composition	Code changes to add/remove	Metadata record, no deploy to wire up
Testing	Handler class tests mixed concerns	Each action tested in isolation
Bypass	Shared disable switch	Per-action bypass via custom permission
Order of execution	Implicit / registration order	Explicit order field on metadata

The metadata-driven composition is the key unlock. Sales can add a TA_Order_Placed action for Order without touching any file owned by Fulfillment. Fulfillment can add its own Order action independently. The trigger file never changes; it's infrastructure, not logic.

Async events: Platform Events

Platform Events are the asynchronous counterpart. Where trigger actions fire synchronously in the DML transaction, Platform Events cross transaction boundaries: publish now, process later, survive failures independently.

The right mental model for on-platform work:

Synchronous (trigger actions): "This just happened in my domain. Process it now, in this transaction."

Asynchronous (Platform Events): "This happened in my domain. Other domains should know about it, at their own pace, in their own transaction, on their own failure boundary."

Both are event-driven. The difference is timing, ownership, and what happens when something fails.

The property that makes it all work: the producer doesn't know its consumers

Here is the single most important thing about messaging, and the reason it cuts coupling where a direct call cannot. It's worth stating on its own because everything downstream depends on it.

When you call something (an Apex method, a @future, a queueable, a REST callout), the caller has to name the callee. The dependency points from producer to consumer. If a second consumer needs to react, you go back and edit the producer to call it too. The producer accumulates knowledge of everyone who depends on it, and every new reaction is a change to the thing that fired the event. That's true even when the call is asynchronous. A @future method is still point-to-point; async timing doesn't decouple anything, it just moves the same hard-wired call off the synchronous path.

Publish/subscribe inverts that arrow. The producer names an event, not a consumer. It announces "this happened" into the bus and is done. It does not know who is listening, and must not care. Consumers register their own interest by subscribing. The dependency now points from consumer to event contract, not from producer to consumer:

Two consequences fall out of this, and both are things a direct call (synchronous or asynchronous) simply cannot give you:

N consumers, zero producer changes. One published fact can fan out to one subscriber or fifty. Adding the fifty-first means deploying the new subscriber. The producer never learns it exists, never recompiles, never gets re-tested. In a point-to-point world, every new reaction is a change to the producer. In pub/sub, new reactions are purely additive and live entirely in the consumer's domain.
The dependency direction is reversed, and that's the whole game. "Who depends on whom" is the question that decides whether you can deploy independently. With a direct call, Sales depends on Fulfillment (it has to know Fulfillment exists to call it). With an event, Fulfillment depends on Sales's event contract (a stable, published fact) and Sales depends on nobody. The domain that owns the data is now ignorant of, and immune to, everyone reacting to it.

This is why "fire an async job" is not the same as "publish an event," even though both run later. The async job still couples the producer to a named consumer. The event doesn't. Decoupling comes from the inverted dependency, not from the asynchrony.

4. The cure: notify, don't reach in

Replace every cross-domain reach-in with a published fact. The domain that owns the data publishes "this happened." Domains that care subscribe and react in their own territory, on their own automation, on their own deploy cadence.

Nothing crosses a boundary except a fact. Fulfillment no longer fires on Order; it reacts to OrderPlaced__e and writes to its own Shipment__c. Finance no longer reaches into Sales's object graph; it subscribes to the same fact and manages its own Invoice__c. Sales can refactor everything behind Order as long as the published fact stays stable. You have drawn a bounded-context border inside one org, using events as the only sanctioned channel across it.

This is the reframe the generic posts miss. The bus isn't a data pipe here. It's a membrane: facts pass through, reach-ins don't. And the data stays exactly where it was, one query away, for whoever legitimately owns the context that needs it.

5. A cautionary tale: the order-handoff anti-pattern

Here is what domain bleed looks like when it wears an event-driven costume.

Imagine an order-to-fulfillment flow that uses platform events to chain processing steps: OrderHandoff_STEP1__e → OrderHandoff_STEP2__e → OrderHandoff_SHIPMENT__e → OrderHandoff_STEP4__e → ... Each step publishes the next event from its finally block:

// OrderHandoff_SHIPMENT handler (in the Sales domain)
} finally {
    if (triggerNext) {
        publishEvent('OrderHandoff_STEP4__e', !hasError);
    }
}

And in the shipment step, the Sales domain directly inserts Shipment__c records, which belong to Fulfillment:

// Sales reaching into Fulfillment's territory
orderToShipmentMap.put(
    orderId,
    new Shipment__c(
        Order__c = orderId,
        CarrierCode__c = orderDetail.CarrierCode__c,
        ServiceLevel__c = orderDetail.ServiceLevel__c,
        // ... a dozen more fields from Sales's data model
    )
);
Database.insert(orderToShipmentMap.values(), false);

The platform events look modern. But look at what Sales is actually doing:

It knows Shipment__c exists in the Fulfillment domain.
It knows the exact field-level schema of that object.
It writes directly to it.
It orchestrates the entire sequence. Fulfillment has no say in when or whether its own records get created.

Sales is reaching into Fulfillment's territory. The events just move the coupling off a shared trigger file and onto the data model. This is "domain bleed in a costume." If Fulfillment adds a required validation rule to Shipment__c, Sales's handoff breaks. If Fulfillment renames a field, Sales breaks. The dependency arrow points the wrong way.

The correct design: Sales publishes OrderPlaced__e carrying just the record ID and the timestamp. Fulfillment subscribes, queries the data it needs (same database, one SOQL call away), and creates its own Shipment__c in its own transaction, on its own schedule, under its own validation rules. Fulfillment owns shipment creation. Sales just announces that an order was placed.

This is the "notify, don't reach in" principle from §4. The event should state a fact in the publisher's past tense. OrderHandoff_SHIPMENT__e is not a fact; it's a command telling a later step to create something specific in another domain. If you can name the one subscriber that's supposed to handle it, you've written a command, and the coupling is still there.

6. A well-designed example: the Support domain

By contrast, the Support domain shows what the pattern looks like when it's right.

When a case is escalated, a Trigger Action publishes a CaseEscalated event outbound. Notice what it doesn't do: it doesn't reach into any other domain, it doesn't write to any other object, and it doesn't know who the subscribers are.

public class TA_Case_Escalated implements TriggerAction.AfterUpdate {
    IEventPublisher eventPublisher;

    public void afterUpdate(List<SObject> triggerNew, List<SObject> triggerOld) {
        Map<Id, Account> accountMap = TA_Case_Queries.getInstance().getAccountMap();

        for (Case c : (List<Case>) triggerNew) {
            if (shouldPublishEvent(c, accountMap)) {
                eventPublisher.addMessage('CaseEscalated', c, c.AccountId);
            }
        }
    }

    private Boolean shouldPublishEvent(Case c, Map<Id, Account> accountMap) {
        Account account = accountMap.get(c.AccountId);
        return account != null && account.Tier__c == 'Enterprise';
    }
}

What's clean about this:

Single responsibility. One action class, one concern. The trigger file is infrastructure: it delegates to MetadataTriggerHandler and contains no logic.
Fact, not command. CaseEscalated names something true in the Support domain's past tense. It doesn't tell anyone what to do with it.
Publisher is indifferent to consumers. Support doesn't know whether an account manager, a downstream warehouse, or a notification system will react. It announces; others decide.
Domain stays in its own territory. The action queries its own data (account tier), publishes to an abstract interface (IEventPublisher), and returns. No cross-domain DML.
The event publisher interface keeps the domain agnostic of the transport layer. Whether the platform event gets bridged to Kafka, routed to a middleware, or handled purely on-platform is infrastructure's concern:

public interface IEventPublisher {
    void addMessage(String messageName, SObject record, Id correlationId);
    void publish();
}

The contrast with the order-handoff flow is instructive. Both use events. Both have Trigger Actions wiring the logic. The difference is entirely in what the event means and who controls the downstream writes.

7. The rule that flips at the boundary

Here's the question that immediately follows "publish a fact": how much do you put in the event?

The microservices world has two answers, named by Martin Fowler:

Event notification: a thin signal. "Order 0061x placed." Just an id and what changed. The subscriber goes and looks if it needs more.
Event-carried state transfer: a fat, self-contained event. Everything a consumer could need, baked in, so it never has to call back.

People argue about which is "right." The argument is unresolvable because the right answer depends on whether the subscriber can cheaply query back, and on Salesforce that answer is different inside the org versus outside it. This is the rule:

Inside the org → thin notification events. The subscriber is in the same database. Re-querying is one cheap, current, transactional SOQL call. This is the Salesforce advantage a distributed system never has: the data is already local. Stuffing state into the event would duplicate data that's right there and instantly stale. So on-platform, publish OrderPlaced__e carrying little more than the record id and the change; let the Fulfillment trigger query the source data itself. Communication, not duplication.

At the external boundary → fat, self-contained facts. The moment the consumer is outside Salesforce, re-querying is expensive and coupling: a callback over the API, an auth handshake, latency, rate limits, and a hard dependency on Salesforce being up. So the events you publish outward should carry the full business fact: everything a downstream system needs to act without calling back.

A common pattern is a single outbound platform event (OutboundEvent__e) that acts as a generic envelope: on-platform triggers add messages via an event publisher interface, which serializes the payload and routes it outward (e.g. through a middleware layer to Kafka). The fat-vs-thin distinction maps cleanly onto that: inside the org, thin signals on domain-specific events; at the outbound envelope boundary, fat self-contained payloads.

And this is where your earlier instinct finally becomes correct: the read model, the projection, the materialized copy all belong downstream, outside Salesforce, fed by the fat boundary events. Not because projections are wrong, but because that is the place where data locality genuinely breaks and a local copy genuinely earns its keep. Inside the org you'd never build one. Across the boundary, you must.

So the same system uses both styles, and choosing by location dissolves the whole thin-vs-fat debate:

	Inside the org	At the external boundary
Subscriber can re-query?	Yes, cheap SOQL	No, expensive callback
Event style	Thin notification	Fat, self-contained fact
Carry full state?	No, it's already local	Yes, consumer can't fetch it
Build a projection?	Never, data is co-located	Yes, downstream where locality breaks
Event's job	Communication + ownership	Communication + data transfer

If you take one thing from this article, take this table. It's where Salesforce's data-locality advantage changes the rules, and where the distributed-systems playbook applies unchanged.

8. Facts, not commands (the bleed wears a costume)

Domain bleed has a sneaky form that survives even after you've "gone event-driven." It's the command disguised as an event:

// Bleed in a costume. Not an event.
CreateShipment__e evt = new CreateShipment__e(OrderId__c = orderId);
EventBus.publish(evt);

CreateShipment__e is not a fact. It's the publisher reaching across a boundary to tell one specific subscriber what to do, just routed through the bus so it looks decoupled. The publisher still knows the shipment step exists, still knows what it should do, still breaks when that domain changes. You've moved the bleed onto the event bus, not removed it.

A real fact names something true in the publisher's domain, in the past tense, and is indifferent to who reacts:

// A fact. Past tense. Publisher's domain. Reaches into no one.
OrderPlaced__e evt = new OrderPlaced__e(
    OrderId__c   = order.Id,
    AccountId__c = order.AccountId,
    PlacedAt__c  = System.now()
);
EventBus.publish(evt);

The litmus test:

A fact says "X happened." A command says "service Y, do Z." If you can name the one subscriber that's supposed to handle it, you've written a command, and the coupling you were trying to cut is still there, now harder to see.

It's the name, not the transport

Here's the crucial point, and it's where a lot of advice goes wrong: a Platform Event can legitimately carry either a fact or a command. Nothing about the platform forces the distinction. The same EventBus.publish() call ships both. The difference lives entirely in how you name and shape the message, and in whether you're honest about which one it is.

You don't need a separate piece of infrastructure (a queue product, a second bus) to carry commands. That's the import error again: borrowing "facts go on the event bus, commands go on a queue" from architectures where those are physically different systems. On Salesforce, both are just Platform Events. What keeps the line honest is naming discipline, not a second transport:

	Fact	Command
Name	Past tense: `OrderPlaced__e`	Imperative: `RecalculateDiscount__e`
Answers	"What happened?"	"What should be done?"
Knows the recipient?	No, indifferent to who reacts	Yes, aimed at a specific handler
Consumers	Zero to many	Exactly one (it's a directed instruction)
Coupling	Publisher depends on no one	Publisher depends on the handler existing

Commands aren't evil; they're necessary. Sometimes you genuinely do need to instruct one specific handler to do one specific thing. The mistake is dressing a command up in fact's clothing (a thin event that looks decoupled but names exactly one intended subscriber) and then believing you've cut the coupling. If it's a command, name it like one: imperative, owned by the caller, pointed at a known handler, so the coupling is at least visible and you can decide whether it belongs. The danger isn't commands on the bus; it's commands pretending to be facts.

9. Who owns the cross-boundary flow? Choreography or orchestration

Once you've drawn borders, some business processes still span them, and you have to decide how they're coordinated. The cheap version of this debate is "choreography good, orchestration bad." It's wrong, and on Salesforce you can fall into the failure mode of either one.

Default to choreography. Facts on the bus; whoever cares reacts. Loosely coupled, scales by addition. Right for "a thing happened, others may want to know."
Reach for orchestration deliberately, when a process spans domains and must complete, needs ordering or end-to-end visibility, or has to be undoable (compensation).

The sentence to tattoo on the team:

Someone has to own the multi-step transaction. Pick the owner on purpose.

The order-handoff anti-pattern from §5 illustrates this. Several steps chained via platform events, each step publishing the next, with no single owner tracking whether the whole thing succeeded. It's "Lambda pinball": an emergent chain nobody owns end-to-end, impossible to trace holistically, with no clean answer to "did the handoff finish, and how do we compensate if a middle step failed?" Per-step observability and error logging helps, but that's a bandage on a structural problem.

The fix is not a central god-orchestrator micromanaging anemic domains. It's a local coordinator: a state machine that owns the process, issues commands, and tracks completion, while the business logic stays in the domain handlers. For long-running, undoable processes you want a saga, where each step registers a compensating action so a half-finished process rolls back cleanly.

One honest caveat: the elegant "just use a local in-process engine" advice from the JVM world assumes a free-form runtime. On Salesforce your coordination primitives are Flow, Platform Events, and async Apex, all under governor limits, so you own the process explicitly within that async model.

The two anti-patterns, both reachable on-platform:

Events that are secretly commands → hidden coupling, no owner.
An orchestrator babysitting steps that are really independent reactions → a bottleneck for nothing.

10. Splitting the monorepo into domains

The architecture above only pays off if you can actually enforce the boundaries it describes. Domain isolation in a Salesforce org isn't just about code style - it's a deployment question.

A repo that takes this seriously reflects it in directory structure. Rather than one flat src/ folder where every team drops files, you organize by bounded context:

src/
├── domain-core/              # Shared infrastructure (trigger       # Event bus infrastructure (platform event objects, routing metadata)
├── domain-sales/             # Leads, opportunities, orders
│   ├── lead-management/
│   ├── opportunity/
│   └── order/
├── domain-fulfillment/       # Shipments, inventory, logistics
│   ├── shipment/
│   ├── inventory/
│   └── logistics/
├── domain-finance/           # Invoicing, billing, payments
├── domain-support/           # Case management
└── _common-modules/          # Cross-cutting UI components and utilities

Each domain is a candidate for its own unlocked package (2GP). A domain can refactor its internals freely as long as the events it publishes stay compatible.

Deployment decoupling is the one that changes how fast your org can move - and it's only reachable once cross-domain communication goes through facts instead of reach-ins.

In a bled org, the deployment unit is the whole org. With events as the only sanctioned cross-domain channel, each domain can become its own independently-shippable unit. Fulfillment deploys on Tuesday. Sales deploys on Thursday. Neither regression-tests the other, because neither reaches into the other's objects.

11. The field guide: Platform Event mechanics that actually decide success

Everything above is design. This is the part where the platform's specific behaviour makes or breaks it. These are fact-checked against current Salesforce documentation, because half the lore floating around is stale.

Publish behaviour, and a footgun

When you define an event you choose when it publishes:

Publish Immediately (default): fires when the publish() call executes, regardless of whether the transaction commits. A subscriber can receive the event before - or even when - the publishing transaction rolls back. Great for fire-regardless and logging-style events; a footgun if the subscriber expects committed data, because you can emit OrderPlaced for an order that then never existed. It counts against a separate limit of 150 EventBus.publish() calls per transaction (Limits.getPublishImmediateDML()).
Publish After Commit: publishes only after the transaction commits successfully, not at all if it fails. Use it when the subscriber will go query the data you just wrote (which, given thin events, is most of the time on-platform). It counts as one DML statement each (Limits.getDMLStatements()).

That distinction interacts directly with §7: thin notification events usually want Publish After Commit, because the subscriber's whole plan is to re-query, and re-querying a rolled-back record is a bug. If you're using a generic outbound envelope event to bridge to external systems, PublishAfterCommit is the right default for exactly this reason.

A successful publish is a successful enqueue, not a delivery

High-volume events (the default for new events since API v45.0) publish asynchronously. After publish() returns success, the request is queued; the actual publish happens when resources free up, and in rare cases the async publish can fail after your synchronous call already returned "success." If you need certainty of the final result, use Apex Publish Callbacks. Don't treat a green publish() as proof of delivery.

Subscribers, and who pays the delivery bill

You get a genuinely broad set of subscriber types: Apex triggers, Flows/processes, empApi (an LWC CometD client, for live UI), Pub/Sub API (gRPC over HTTP/2, the modern external path), and CometD (legacy). Worth knowing: Apex triggers, processes, and flows don't count against the event delivery allocation - only CometD-style clients do, and for empApi it's metered per channel, per browser session.

Durability - the bus is not an event store

Retention: high-volume events live in the bus for 72 hours; the older standard-volume events (definable only before Spring '19, now being retired) for 24 hours. Then purged.
Max message size: 1 MB. Fat events still have a ceiling - another reason the fat ones belong at the boundary, carrying a business fact, not a kitchen sink.
No SOQL/SOSL on events, no reports, no list views. If you need to see that an event fired, you persist a trace yourself. Events are shouted, not stored.

This is the deepest reason §7's projections live downstream: the platform deliberately doesn't durably store events, so your long-term, replayable, queryable copy belongs on a real log (Kafka/Redpanda) that is built for retention - outside Salesforce.

Scaling out: it's broadcast, not consumer groups

The intuitive Kafka model: add consumers, partitions distribute, each message processed once - does not apply to external Salesforce subscribers. Per Salesforce's own docs, if you start multiple Pub/Sub API subscriptions for the same org and topic, each stream is independent and the same events are delivered to every subscriber. Scale a gRPC connector from one pod to three and you get every event three times, not a third each. The burden is deduplication (on the EventUuid / id field), not partition assignment. To actually parallelise, consume once and fan the work onto a real log with real consumer groups.
The one place you get competing-consumer semantics is on-platform: Apex parallel subscribers, where one trigger runs as multiple concurrent instances and Salesforce assigns each event to exactly one, partitioned by a key (default: a hash of EventUUID, which randomises, and therefore does not preserve order). Need ordering within an entity? Set the partition key to that entity's id: ordered within a key, parallel across keys, exactly like a Kafka partition key.

Errors, retries, and the replay asymmetry

Inside an Apex subscriber you get a real retry model: throw EventBus.RetryableException and the batch is resent after an increasing delay, in original ReplayId order, up to 10 total runs (initial + 9 retries) before the subscription moves to an error state. Read the attempt count via EventBus.TriggerContext.currentContext().retries so you cap your own retries:

trigger OrderPlacedTrigger on OrderPlaced__e (after insert) {
    try {
        FulfillmentService.handle(Trigger.New);
    } catch (Exception e) {
        if (EventBus.TriggerContext.currentContext().retries < 6) {
            throw new EventBus.RetryableException(e.getMessage());
        }
        Logger.error('OrderPlaced handler exhausted retries', e);
    }
}

For partially-processed batches, checkpoint with EventBus.TriggerContext.currentContext().setResumeCheckpoint(replayId) so a retry resumes after the last success instead of redoing it - important because uncatchable limit exceptions (DML/SOQL governor limits) can't be caught, and an un-checkpointed batch's unprocessed events aren't redelivered.

The asymmetry to remember: there is no Apex API to replay an arbitrary historical event by ReplayId. From Apex you can resume a suspended subscription (from earliest, or "from tip" to skip poison events), checkpoint within a batch, or publish a new event - but arbitrary replay-by-id within the retention window is an external-subscriber capability (Pub/Sub API and CometD let you subscribe from Earliest, Latest, or a custom ReplayId). Once again: durable replay lives downstream, not in Apex.

12. The one thing the integrated platform gives you that Kafka doesn't

For all the constraints, Platform Events have a genuinely lovely property a raw Kafka setup lacks: one fact can drive backend logic and live UI at the same time, with almost no extra plumbing.

Backend: an Apex trigger on the __e reacts and runs domain logic.
Frontend: an LWC subscribes to the same channel via empApi and updates in real time.

import { subscribe, unsubscribe, onError } from 'lightning/empApi';

connectedCallback() {
    subscribe('/event/OrderPlaced__e', -1, (response) => {
        this.handleEvent(response.data.payload);
    }).then((sub) => { this.subscription = sub; });
    onError((error) => console.error('empApi error', JSON.stringify(error)));
}
disconnectedCallback() { unsubscribe(this.subscription, () => {}); }

A single OrderPlaced__e, published once, can drive backend logic (Apex), refresh an ops team's live dashboard (LWC), and hit Kafka for the rest of the company (Pub/Sub API bridge). This is the producer-knows-no-consumers property from §3 made vivid: three subscribers across two completely different runtimes - Apex and JavaScript - and the publisher knows about none of them. Add a fourth and the publisher still doesn't change. One fact, N consumers, zero coupling between them - provided the fact is a fact and not RefreshOrdersDashboard in disguise. Operationally, remember empApi is a CometD client and meters per browser session, so a thousand open dashboards is a thousand subscriptions.

13. The contras, stated plainly

This is not friction-free, and the JVM-world defaults don't all survive contact with the platform:

The bus is not a store. 72h / 24h retention, no SOQL, no native audit. Durability is your job - downstream.
No arbitrary replay from Apex. Suspend/resume and checkpoints only; true replay-by-id is external.
Fan-out, not consumer groups, for external subscribers. Scaling out means deduping, not load balancing.
Governor and async limits constrain orchestration. Local-engine sagas don't port one-to-one.
1 MB cap and limited field types. Fat events have a ceiling.
Publish-immediate footgun. Events can reference data that never committed.
Observability tax. You trade the easy end-to-end call stack for emergent flows. Eventual consistency becomes something you engineer - idempotent handlers, lag monitoring, reconciliation for any fire-and-forget fan-out with an SLA.
Trigger action discipline. Single-responsibility actions only pay off if the team enforces it. Without governance on Trigger_Action__mdt, you end up with the same chaos as the old shared handler class, just in metadata form.

Borders cost discipline. Bleed costs velocity. Pick your bill.

14. Finding the borders: event storming

Everything so far assumes you already know where the boundaries are and which facts matter. In a mature org you usually don't - the knowledge is scattered across the heads of admins, developers, and the business people who actually understand the process. Event storming is the workshop technique for getting it out of those heads and onto a wall before you write a line of Apex.

The mechanics are deliberately low-tech: a long roll of paper (or a digital whiteboard) and sticky notes in a few colours. You get the people who know the business in one room and reconstruct what actually happens, using a fixed vocabulary of colours:

Orange: domain events (facts). Something that happened, past tense: Order Placed, Shipment Dispatched, Invoice Issued. You brainstorm these first and arrange them left-to-right in time. This is the raw material for your Platform Events.
Blue: commands. The action or decision that caused an event: Place Order, Dispatch Shipment. Note the one-to-one feel - a command, when it succeeds, produces an event. This is exactly the fact-vs-command distinction from §8, discovered on the wall before it's encoded in a name.
Yellow: actors / roles. Who issues the command - a sales rep, a warehouse operator, a system integration.
Pink: external systems. Anything outside the org that emits or receives - the payment gateway, the carrier's shipping API. These pink notes are where your fat boundary events from §7 will live.
Purple: policies. "Whenever this event happens, that command should fire." Purple notes are the reactive glue - and crucially, they reveal cross-domain reach-ins. A policy that says "whenever Order Placed, create the Shipment" is the order-handoff anti-pattern from §5, caught on a sticky note.

The borders emerge on their own. As the orange events line up across the timeline, you'll see them cluster - a run of sales facts, then a run of fulfillment facts, then finance. The seams between the clusters are your bounded contexts. You didn't impose them top-down; the language did. Where the business stops using one set of nouns and starts using another is exactly where one domain ends and the next begins. Draw a vertical line there and you've found a border to defend with an event.

What event storming gives you, concretely, before any migration:

A candidate list of Platform Events - every orange note is a fact you might publish.
The bounded contexts - the clusters become your domain-* packages from §10.
The reach-ins to kill - every purple policy that crosses a cluster line is a place a domain is reaching into another's territory. Those are your refactor targets, prioritised by how much pain they cause.
A shared language - the admins and developers now describe the system the same way, which is half the battle in cutting domain bleed.

You don't need a two-day formal workshop to start. Even a 90-minute "big picture" storm of one painful flow - the order handoff, say - will surface more hidden coupling than a week of reading code, because it pulls in the people who know what the system is supposed to do, not just what it currently does.

15. How to get there without a rewrite

You don't refactor a twelve-year-old org in one go. Use branching by abstraction:

Keep internals as they are.
Define a clean set of facts at each context's edge and publish them - thin on-platform, and bridged (e.g. via Redpanda Connect) to a real log as fat boundary facts for the wider company.
Move downstream consumers onto that durable, properly-partitioned stream instead of subscribing to raw Platform Events.
Migrate trigger logic from shared handler classes to Trigger Actions, one object at a time - the metadata-driven composition means you can wire up new actions without touching the trigger file.
Peel domains into their own packages behind those stable contracts, on your own schedule.

The facts are the contract. Everything behind them is yours to modernise; everything in front sees clean borders - even while the engine room is mid-renovation.

The hardest part isn't the platform mechanics - it's the cultural shift. Publishing a fact and trusting other domains to react is slower in the short term than reaching in and doing it yourself. The order-handoff anti-pattern from §5 exists because it works - it's just not owned. Inverting it requires accepting that a domain's records are that domain's responsibility, even when another domain is the trigger for creating them. That discipline is what makes independent deployability real.

16. Takeaways

Treat domain boundaries as if they were network boundaries. Distributed systems engineers get this for free; on Salesforce you have to enforce it yourself. The discipline is identical - only the mechanism differs.
The shared database is your advantage, not your problem. Distributed systems copy data across service boundaries because they have no choice. You can re-query. Use it - keep events thin on-platform, fat only at the external boundary.
There are two kinds of event-driven Salesforce. Triggers are synchronous events; Platform Events are async. Both require the same ownership discipline; the difference is timing and failure boundaries.
Trigger ownership is an architecture decision. A trigger owned by everyone is owned by nobody. Trigger Actions with metadata-driven composition give you single responsibility, independent deploy, and explicit ordering - the same guarantees a service boundary gives a distributed system.
Domain bleed is the core failure mode - one domain reaching into another's objects, queries, and automation. Events are the membrane: facts cross boundaries, reach-ins don't.
Facts, not commands. If you can name the one subscriber meant to handle it, you've written a command. The coupling is still there, just on the bus now.
Thin inside, fat at the external boundary. Inside the org, thin notifications - the data is a query away. Outward, fat self-contained facts. That's the only place a read model projection belongs.
Pick the owner of every cross-domain flow on purpose. Default to choreography; reach for orchestration when a process must complete end-to-end and someone needs to own whether it did.
Split your repo into domains. Directory structure is the first step toward independent packages. Code isolation is the prerequisite for deployment isolation.
Know the mechanics cold - publish behaviour, async publish + callbacks, retention, broadcast vs parallel subscribers, retry/checkpoint, no-arbitrary-replay-from-Apex.
The prize is independent deployability. Distributed systems get it from service boundaries. You get it from event contracts. Same outcome, different path.

The platform is a tool, not an identity. Distributed systems engineers don't get credit for their hard boundaries - the network just forces them. The work on Salesforce is choosing to hold those same boundaries when nothing makes you.

So don't wait for a rewrite, and don't try to redraw the whole org at once. On your next change, find one place where a domain reaches across a boundary it doesn't own - one trigger, one cross-domain write, one query reaching three objects deep - and replace just that reach-in with a published fact. Draw one border. That single event is the first place your org starts behaving like the distributed system it always secretly was.

Glossary

This article borrows vocabulary from distributed systems and domain-driven design. If you came up through the admin/declarative side of Salesforce, here's the plain-English version of each term, in roughly the order it appears.

Domain / subdomain. A cohesive area of the business with its own data and rules - Sales, Fulfillment, Finance. On Salesforce, a domain is the set of objects, automation, and code one team owns. The opposite of "one big shared org where everyone edits everything."
Bounded context. The boundary around a domain inside which a word means exactly one thing. "Account" might mean a prospect in Sales and a billing entity in Finance; a bounded context is where you decide which. The seam between two contexts is exactly where you draw a border and put an event.
Domain bleed. This article's term for one domain's logic running inside another's territory - querying its objects, firing on its records, or writing its fields. The disease the whole article is about.
Coupling. How much one piece of code depends on another. Tight coupling means changing A forces you to change (and re-test) B. The goal is loose coupling - domains that can change independently.
Distributed monolith. A system split into pieces that still have to deploy together because they're too entangled - all the cost of being distributed, none of the independence. The "non-distributed monolith" is the Salesforce mirror image: one org, but the same entanglement.
Fact vs command. A fact (or domain event) states something that already happened, past tense: OrderPlaced. A command instructs a specific handler to do something: CreateShipment. Both can ride on a Platform Event - the difference is naming and intent (see §8).
Producer / consumer (publish / subscribe). The producer publishes a message and doesn't know who's listening. Consumers subscribe to declare their own interest. This is what "the producer doesn't know its consumers" means - the dependency points from consumer to event, not the other way around.
Event notification (thin) vs event-carried state transfer (fat). A thin event carries just an id and what changed; the subscriber re-queries for details. A fat event carries the whole payload so the subscriber never has to call back. Thin inside the org, fat at the external boundary (see §7).
Projection / read model. A pre-built copy of data, shaped for fast reading, kept in sync by listening to events. On-platform you almost never need one (you can just SOQL the source). Downstream of Salesforce - in Kafka, a warehouse - you build them because re-querying across the boundary is expensive.
CQRS (Command Query Responsibility Segregation). The pattern of separating the write side (commands) from the read side (queries/projections). Mentioned mainly to say: it's a downstream concern, not something you build inside the org.

Why Salesforce Debug Logs suck and how I fixed them

René Knierim — Sun, 21 Jun 2026 09:11:34 +0000

If you are a Salesforce Developer, you know the drill:

Develop
Deploy
Enable Debug Logs for a User or open Developer Console
Test
Something breaks -> inspect the Debug log
Download the Debug log and use it with the Apex Log Replayer

For me, this always felt a bit icky. Why do I have to go through a full release cycle, interact with the org, and find and download the log to even get the most basic information about what happened in the backend?

And that's one of the keywords here. Something already happened. I created an error on the Org that I might even share with other people and developers. Let alone if it is a production org that faces this issue. Every fix I deploy will affect other people and needs to go through a full release cycle, just to check again retrospectively if it is fixed.

Apex again is the odd one out in the world of programming languages. Its historic strength to develop directly against the platform turns out to be a big time consumer on complex orgs.

Debugging at Runtime

Imagine for a second you are not a Salesforce developer, but you develop in Java, Go, Kotlin, Swift or any other widely used programming language. There is no Org, no server you deploy to, nothing that generates Debug Logs for you during your dev cycle to debug issues.
Instead, you can execute those languages on your machine. And because they execute on the machine, your IDE enables you to set breakpoints and inspect every single variable. All that without going through a release cycle to a Sandbox or a Scratch org. And all that without cluttering your machine with tons and tons of old debug logs that you forgot to delete.
If this is something you have dealt with in the past and would like to experience the same comfort as developers in other languages, having a look into Nimbus might be worth your time

Nimbus is a full local Apex Runtime and Debugger. It runs your Apex code against an embedded database as if you were on a Salesforce org, with the only difference that you don't need a Sandbox or a Scratch Org to verify what you have built

Set up Nimbus in less than a minute: https://github.com/nimbus-solution/nimbus and go Pro for free

Get the VSCode and IntelliJ plugins and improve you development cycle today!

Found something that doesn't work as expected? Leave us an issue in GitHub or reach out to us directly in our Slack community