Salesforce consultancy: five clients, five orgs, one laptop

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

Who this is for

Practice leads, delivery managers and senior developers at Salesforce consultancies and system integrators: anyone whose people bill hours to more than one client org. No prior contact with a local runtime is assumed; What is a local Apex runtime? goes deeper.

Why does the org round trip cost a consultancy more than an in-house team?

An in-house Apex developer has one org problem: the sandbox is slow, shared and four minutes away. A consultant has it once per client, and the clients do not coordinate.

Each client owns its own access: a VPN, a user an admin has to create, a permission set someone has to assign, multi-factor authentication on a device the client issued. Each has its own deploy queue and its own shared sandbox, where the client’s admins, a second vendor and your team push into the same metadata and test data. The smallest unit of work, change a class, run its tests, read the result, is bracketed by the slowest parts of five IT estates.

In every other ecosystem a consultant does none of this. A Java contractor clones the repository and runs mvn test; a JavaScript contractor runs npm test. The compiler, the runtime and the database are on the laptop; the client’s infrastructure is for deploying. Salesforce never offered that, because the Apex compiler and runtime live in Salesforce’s data centres, so an Apex test could only run inside an org. That is the constraint a local runtime removes.

What is a local Apex runtime, and what does it change for consultancy work?

renmy runtime is a local Salesforce Apex runtime and developer toolchain: an interpreter for Apex (classes, interfaces, enums, generics, triggers), for SOQL and DML, and for Salesforce Flows (autolaunched, record-triggered and screen), running 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. Not a mock, not a transpiler: governor limits are enforced, Test.startTest and Test.stopTest, @testSetup, per-test transaction isolation and the Stub API behave as in an org, and triggers and flows fire in order of execution. How closely it matches the platform is a public record: renmy.net/parity.

Every client repository is a standard SFDX project, and a standard SFDX project is all the runtime needs. Nothing about the client’s org is required to run the tests.

# Three clients, three standard SFDX projects, one machine.
# No VPN, no org login and no deploy in any of these lines.
cd ~/clients/client-a && renmy test "*"
cd ~/clients/client-b && renmy test "InvoiceServiceTest.*" --coverage
cd ~/clients/client-c && renmy validate

The published benchmark runs four open-source Apex suites, 837 tests, both ways: about 1 min 46 s to deploy and run in a Salesforce org, 2.4 s on renmy runtime, every test passing in both (benchmarks).

I already have a sandbox for each client. Why would I need this?

You keep every one of them. The sandbox is where the deploy lands, where the client’s admins click through a screen flow, where the integration to the ERP is checked; final validation and deployment happen in Salesforce. What moves to the laptop is the one activity that never needed an org and happens more often than everything else combined: running Apex tests against the code you just changed. The sandbox stays where you ship; the laptop becomes where you find out whether to. See renmy runtime vs scratch orgs and The scratch org tax.

The utilisation arithmetic

Three numbers: minutes per change, changes per day, billable rate. Multiply them for what the org round trip costs one developer per day; multiply by the bench for the practice. The first is the one you do not set: a push to the shared sandbox, a four-minute wait, a result that may be about another team’s test data. The second is higher than your people estimate, because every quick check counts. The third is your rate card.

Two things make this worse for a consultancy. On a fixed-price project the price was set before the waiting began, so every minute watching a deploy is margin, not revenue. On time and materials the client pays for the minute and receives nothing for it, and “waiting for your sandbox” is the hardest line on an invoice to defend.

The teams page has a calculator with every input exposed. With its defaults, a team of five gets back 2.4 hours per developer per week and the plan pays for itself in 14 working days. Put in your own numbers, with the rate on the invoice rather than the payslip.

How does one laptop hold five clients’ projects?

The runtime reads the project in the directory you run it in, so several clients means several directories.

• Settings live in the repository. renmy init writes the settings file, nimbus.properties (a renmy.properties is read too). Committed with the code, it gives everyone who clones the repository the same configuration; CI overrides use the %ci. prefix.
• The schema comes from the metadata. renmy sync builds the local schema from the project’s object metadata, or from an org; renmy fixture generates a test data factory from it.
• Test data is Apex, as in an org. Each test runs in its own transaction and is rolled back: no seed plan per client, no leftover rows from the last project.
• Managed packages are stubbed. renmy stub covers the package types the org hides and your code calls: renmy.net/managed-packages.
• The code goes nowhere. Apex source, schema and test data are read and executed on the laptop; nothing is sent to Renmy UG. For the client’s security questionnaire and your NDA, that is the sentence: renmy.net/security.

Credentials come out to deploy, and only then

The client’s org login happens as it does today, through the Salesforce CLI; renmy sf <anything> passes any Salesforce CLI command through unchanged. renmy deploy is a gated one-shot deploy, and it is Free: it snapshots the selected source into a bundle, runs the local test and coverage gates against that bundle, validates the identical bytes in the target org with a real check-only validation, and only then deploys.

# The one step that touches the client's org.
renmy sf org login web --alias client-a-uat

# Local gates, a real check-only validation of the same bytes in the org,
# then the deploy.
renmy deploy --source-dir force-app --min-coverage 75

Clients who want a person between validation and production get the split version, renmy release validate and renmy release deploy, with a receipt: renmy.net/release (Pro, free during the beta).

Where does CI go when the client owns the pipeline?

A pipeline per client, each with the shape the CI page describes: authenticate to a Dev Hub with a JWT certificate, create a scratch org from a finite pool, deploy for four to eight minutes, test for another three to five, delete the org if nothing crashed. Twelve to twenty minutes per run, failing whenever the pool is empty, the certificate has expired or the network is slow, on a different day per client. With the tests on the runner, the job needs one secret and no org:

name: Apex tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: Run Apex tests
        run: |
          renmy test "*" \
            --coverage --coverage-report coverage.xml \
            --results-xml results.xml
        env:
          # The only secret in the job. CI runs are part of Team, free during the public beta.
          NIMBUS_LICENSE_KEY: ${{ secrets.NIMBUS_LICENSE_KEY }}
          NIMBUS_PROFILE: ci

Thirty to ninety seconds, JUnit XML for the pull request and Cobertura XML for the coverage dashboard, line and branch. The GitLab CI version is on renmy.net/ci; the wiring is in Apex CI without an org. For a consultancy this is one pipeline shape carried from client to client, the client’s org appearing only in the deploy job. Hand it over at the end of the engagement and it keeps working without your JWT certificate in their secrets store. CI runs are part of the Team plan.

Who buys the licence, the consultancy or the client?

An individual consultant can run every client’s suite on the Free tier: unlimited local test runs, gated deploys, CLI pass-through and IDE integration, one machine, no card. A consultancy that wants the bench on the same footing buys Team: a seat per developer with three machines per seat, everything in Pro, test and release runs in CI, a dedicated CI runner licence, and the licence management portal for assigning and revoking seats. A seat follows the person, not the project, so a developer rolling off one client onto the next needs nothing new. Team lists at $49 per developer per month, three seats minimum, free during the public beta.

When the client wants the pipeline and the seats under its own contract, the client buys. Enterprise starts at $20,000 per year: unlimited seats and CI runners, a support SLA, DPA, PO and invoice billing, SSO on request, on-premise licence validation for air-gapped runners. It is a custom contract; a consultancy that wants to hold the licence on a client’s behalf raises it at sales@renmy.net. Pricing is public at renmy.net/#pricing and in detail on renmy.net/teams; the onboarding side is Onboard a Salesforce developer on day one, without an org.

What Renmy UG does as a consultancy itself

Renmy UG also takes engagements; here they are, peer to peer. The Health Check is €7,500 or $8,500 net, about two weeks. The Release Process Sprint runs two to four weeks at a fixed scope. The Org-less CI setup is $7,500 to $25,000 by Apex surface, two weeks: week one brings the client’s metadata into a clean source-controlled project, week two gets every test class running locally to a parity target fixed in the statement of work; the fee is credited against Enterprise if the client buys within a year. Fixed price, net, for businesses only. If a client of yours still has its Apex only in the org, that setup is what makes everything above possible, and a consultancy can run it itself; the shape of the work is on renmy.net/consulting.

Try it

curl -fsSL https://renmy.net/install.sh | sh          # macOS, Linux
irm https://renmy.net/install.ps1 | iex              # Windows PowerShell
cd a-client-project
renmy test "*"

The quickstart gets you to a first green run. Issues, docs, examples and the released binaries are at github.com/renmy-solutions/renmy. The same runtime runs from the editor through the VS Code extension and the JetBrains plugin, Renmy Runtime - Salesforce IDE; in the latter, anything that writes to an org asks first and names the org. Questions: the Slack.

Frequently asked questions

Can one laptop run Apex tests for several clients’ Salesforce projects?

Yes. renmy runtime reads the standard SFDX project in the directory it is run in, so each client is a directory with its own committed settings file. No org login, VPN or sandbox is involved in a test run; the client’s credentials are needed only to deploy, through the Salesforce CLI.

Does the client’s code or data leave the consultant’s machine?

No. Apex source, schema and test data are read and executed locally against an embedded PostgreSQL, and nothing is uploaded to Renmy UG. The security page at renmy.net/security documents network behaviour and licence validation in full.

Who buys the licence, the consultancy or the client?

Either. An individual consultant can use the Free tier on one machine. A consultancy buys Team seats for its own developers and moves them between projects in the licence management portal; a client that wants the pipeline under its own contract buys Team or Enterprise. Pro and Team are free during the public beta; Team lists at $49 per developer per month, Enterprise from $20,000 per year.

Does a local Apex runtime replace the client’s sandboxes?

No. Final validation and deployment happen in Salesforce, and anything a browser or an external system needs still happens in an org. What moves to the laptop is the Apex test loop, the step the org was only slowing down.