Onboarding Salesforce developers: day one, without an org

renmy runtime was called Nimbus until October 2026. Same tool, same binary; the record of the rename is at Nimbus is now renmy runtime.

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:

1. Request a sandbox, or a seat in the shared one. An admin has to act.
2. Request a user in it, with the right profile and permission sets. Another admin, another day.
3. Get on the VPN, authorise the Salesforce CLI.
4. Push the repository to the sandbox, which already holds somebody else’s branch.
5. 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 NIMBUS_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:
          NIMBUS_LICENSE_KEY: ${{ secrets.NIMBUS_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 licence key from the portal through the NIMBUS_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

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

The quickstart has the install in detail; source, issues, docs and released binaries are at github.com/renmy-solutions/renmy; 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.