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

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. If the request still says Nimbus: Nimbus was renamed renmy runtime in October 2026, same tool, same binary; the record of the rename has the details.

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 NIMBUS_ 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": "NIMBUS-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 NIMBUS_TELEMETRY=false

# NIMBUS_NO_TELEMETRY=1 and NIMBUS_NO_TRACKING=1
# are honoured as well

Every one of these also disables the CI activation event. A build server with NIMBUS_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 NIMBUS_TELEMETRY=false
# and the daily update check
export NIMBUS_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:

• 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 and 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: NIMBUS_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 NIMBUS_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.