renmy runtime vs scratch orgs

What each one is

Scratch orgs

A scratch org is a temporary, configurable Salesforce org provisioned from your DevHub. It has full platform fidelity: every feature works exactly as it does in production. Each developer typically gets their own, so there's no shared state. The catch: provisioning takes 30 seconds to several minutes, your source has to be pushed, and the org sits behind DevHub's daily and active limits (100 active / 200 per day for most editions).

renmy runtime

renmy runtime runs a complete Apex interpreter on your machine with an embedded PostgreSQL. SOQL executes as real SQL, triggers fire on DML, flows run from your .flow-meta.xml files, and each test runs in an isolated transaction. It needs no org, no credentials, and no internet connection. Tests typically finish in tens of milliseconds.

Timings and costs

• Test run time, single test: scratch org ~5–15 seconds (deploy + execute + retrieve); renmy runtime ~10–200 ms.
• Full suite (1000 tests): scratch org 8–20 minutes; renmy runtime 30–90 seconds.
• First-time setup: scratch org 5–30 minutes (config, push, install); renmy runtime < 1 minute (single binary).
• Operational cost: scratch org consumes DevHub limits and CI minutes; renmy runtime runs on your laptop or CI runner, with no external service.
• Credentials needed: scratch org requires JWT cert, connected app, DevHub access; renmy runtime needs none.

Where scratch orgs win

• Full platform features. Sharing rules, Visualforce/LWC rendering, real platform events end-to-end. renmy runtime implements some of these, not all.
• Governor-limit fidelity. Heap size and CPU time are measured against Salesforce's own platform hardware. renmy runtime can track structural limits (SOQL rows, DML statements) but resource-based limits aren't comparable across machines.
• Pre-deployment validation. The last gate before production, run on a real org to verify the deploy itself works.
• UI work. Anything that requires the org UI to render and respond.

Where renmy runtime wins

• Edit-and-run speed. Edit a class, save, and see the results in milliseconds. The same cycle with a scratch org takes minutes.
• Offline. renmy runtime runs on a train, on a plane, or in a coffee shop with no Wi-Fi.
• CI without an org. No JWT cert, no DevHub limits, no scratch org pool to exhaust. Standard JUnit XML and Cobertura XML plug into GitHub Actions, GitLab, SonarQube, Codecov.
• AI agents. Agents write, test and fix in a cycle that only works when tests run in seconds. renmy runtime gives Claude Code, Cursor, and Copilot that cycle for Apex, the way Python and TypeScript already have it.
• Per-developer cost. No DevHub limit consumed for every developer running tests all day.

How teams use them together

The pattern we see most often:

1. Local development: renmy runtime for every test run during active work. Watch mode re-runs affected tests on save.
2. Pull-request CI: renmy runtime runs the full suite as the merge gate. JUnit XML + Cobertura plug into the existing CI.
3. Pre-deployment: a scratch org or sandbox runs the same tests as the final platform-fidelity check before promoting to production.

The DevHub-heavy "every PR provisions a scratch org" pattern goes away. Scratch orgs become a deployment-validation tool rather than a development dependency.

What changes when you migrate

# Before: scratch-org loop
sf org create scratch -f config/project-scratch-def.json -d
sf project deploy start
sf apex run test --class-names AccountServiceTest --result-format json --wait 10

# After: the renmy loop
renmy test AccountServiceTest

renmy runtime reads your sfdx-project.json, classes, triggers, and flows in place. There is no copying, no parallel project, and no separate set of test files. The same @isTest classes that run on the platform run locally.