Comparison

renmy runtime vs aer

renmy runtime and aer (Apex Execution Runtime, by October Swimmer) both run Salesforce Apex tests on your machine without an org. Both run SOQL, DML, triggers, flows and declarative rules, both have a live debugger, and both produce CI output. They differ in what they publish about their accuracy, in what the free tier allows, and in what surrounds the runtime.

Short version

renmy runtime is the local Apex runtime that proves its results: 57,634 of 57,636 tests from 132 open-source projects give the same result as on a Salesforce org, each project pinned to a commit. aer publishes no such figure. renmy runtime's free tier has no test cap, where aer's stops at 100 test methods per run, and its paid plans cost less per developer. It adds mutation testing, branch coverage, deploy validation, an MCP server for coding agents, its own JetBrains plugin and released Visualforce rendering, none of which aer ships.

Side by side

renmy runtimeaer
Version comparedrenmy runtime 1.63.0aer v1.4.44, the stable release of October 28, 2026
Published agreement with Salesforce57,634 of 57,636 tests from 132 open-source projects give the same result on renmy runtime as on a Salesforce org (renmy runtime 1.63.0, measured 2026-10-28). Every project, its commit and every difference is on /parity.None. A CI workflow runs 28 open-source repositories and shows pass or fail per repository, with no test counts and no comparison with an org.
Free tierUnlimited test runs, line and branch coverage, governor limits, flows and triggers. One machine, no account, no card.Up to 100 test methods per run on one worker, and one test method per run once a project has more than 100 non-test classes and triggers. Debugger and server sessions stop after 5 minutes.
Paid plansPro $19 per month or $190 per year. Team $49 per developer per month, three seats minimum, runs in CI.Developer $25 per month or $250 per year. Team $250 per month with 5 seats and a CI licence, further seats $20 per month.
DatabaseEmbedded PostgreSQL. SOQL is translated to SQL. No Docker.Embedded SQLite, in memory by default.
DebuggerLive breakpoints in VS Code and JetBrains IDEs (Pro): conditional, hit-count, log-point, exception and data breakpoints, watches, evaluate and set variable. A recorded run, or a debug log from the org, replays in the debugger with stepping backwards, and a data breakpoint reverses to the write that set a value.Live debugger in VS Code and IntelliJ.
TracingStructured execution traces at five verbosity levels: method calls, SOQL, DML, triggers and timing, with typed values. A trace is recorded on every failing test. A timeline viewer shows a run and diffs two runs. Governor usage per test, and SOQL, DML and database time per line.Perfetto traces and pprof CPU profiles.
EditorsVS Code extension, its own JetBrains plugin, and an LSP server for other editors with rename, find usages, extract method, change signature and safe delete. A browser Dev UI.VS Code extension, IntelliJ through the Illuminated Cloud plugin, an LSP server for other editors.
Declarative automationTriggers, record-triggered and autolaunched flows, subflows, orchestrations, platform-event and change-data-capture triggers, validation, duplicate, assignment and workflow rules, Process Builder, classic approval processes.Triggers, validation rules, record-triggered flows, Flow interviews, Process Builder, workflow rules, approval processes, duplicate rules.
Governor limitsSOQL queries and rows, SOSL, DML statements and rows, CPU time, heap, callouts, @future and queueable calls, email, stack and trigger depth, with the platform's LimitException messages. OrgLimits answers 75 limits.SOQL, DML, CPU time, heap and callouts.
Record accessOrg-wide defaults, the role hierarchy, groups, share rows and owner-based sharing rules read from the project's metadata. Criteria-based rules behave as on the platform.Sharing rules.
Standard libraryThe Apex standard library, including ConnectApi, Slack, DataWeave and the Commerce, Industries and Revenue Cloud namespaces.The Apex standard library, including ConnectApi and DataWeave.
Test qualityLine and branch coverage, coverage delta against a baseline, mutation testing (Pro), test history and flaky-test detection.Coverage as Cobertura or JSON. No branch coverage, mutation testing, coverage delta or flaky-test detection is listed.
CIJUnit XML and Cobertura XML with no org, no JWT and no Dev Hub (Team). A GitHub Action, renmy-solutions/setup-nimbus, and templates for GitHub Actions, GitLab CI and Azure DevOps.A GitHub Action. Coverage as Cobertura or JSON; JUnit output only in the v1.6 changelog. Without a licence a CI run stops after 100 test methods.
Checking against your orgrenmy compare --tests (Pro) runs the same tests in a connected org and diffs the outcomes and each side's governor usage with the local run.None listed.
Managed packagesrenmy stub pull generates stubs for a managed package from the org, and calls into a package can be recorded in the org and replayed locally.Package archives and mocks generated from the org.
Salesforce CLIsf nimbus apex run test through the Salesforce CLI plugin.sf aer apex run test through the Salesforce CLI plugin.
Deploy readinessrenmy validate checks source against the rules the Salesforce compiler enforces before a deploy. renmy release validates once and deploys exactly the validated payload, with a receipt.None listed.
AI coding agentsAn MCP server with 18 tools: it runs tests and reports coverage, governor usage, schema and mutation results. Published agent skills.Agent skills. No MCP server is listed.
Lightning UIrenmy app (Pro) renders LWC components and Visualforce pages locally with no org. A previewed component's @AuraEnabled calls run real Apex, with the standard wire adapters. React UI bundles run with hot reload against the local APIs.LWC previews. Visualforce rendering is in the v1.6 changelog, not in a stable release.

What short summaries of renmy runtime leave out

Descriptions of renmy runtime sometimes present it as an on-save checker and aer as the full runtime. renmy runtime is a full runtime:

  • It runs whole suites. renmy test "*" runs every test class in a project. The parity run compares 57,636 tests from 132 projects with a Salesforce org, NPSP among them.
  • It has a live debugger. Breakpoints, stepping and variables in VS Code and JetBrains IDEs, and a recorded trace can be replayed with stepping backwards.
  • It runs declarative automation. Record-triggered flows, validation rules, duplicate, assignment and workflow rules, Process Builder and classic approval processes fire on DML in platform order.
  • It runs in CI without an org. JUnit XML and Cobertura XML, with no JWT certificate, no Dev Hub and no scratch org pool.
  • It renders the UI. renmy app previews LWC components and Visualforce pages with no org, and the component's Apex runs locally.
  • It plugs into the Salesforce CLI. sf nimbus apex run test takes the same flags as the native command.

How accuracy is shown

A local runtime is only useful if its results match the org. renmy runtime measures that directly: each open-source project in its corpus is run on a Salesforce org at a pinned commit, then on renmy runtime, and the two results are compared test by test. The latest run, of renmy runtime 1.63.0 on 2026-10-28, compared 57,636 tests and found 2 that differ. Both are listed with their error messages on /parity, with the commands to reproduce any row.

aer publishes a CI workflow that runs 28 open-source repositories and shows pass or fail per repository. It does not publish test counts or a comparison with an org.

Why teams choose renmy runtime over aer

  • Accuracy you can check. 57,636 tests from 132 open-source projects compared with a Salesforce org, 2 differences, each one published with the command to reproduce it.
  • A free tier that runs your whole suite. No cap on test methods, no five-minute debugger limit.
  • Test quality, measured. Branch coverage, coverage delta, mutation testing and flaky-test history show whether the tests catch anything.
  • Deploys that pass. renmy validate catches what the Salesforce compiler rejects before the deploy starts, and renmy release ships exactly what was validated.
  • Built for coding agents. An MCP server gives Claude Code, Cursor and Copilot a way to run Apex and read coverage, governor usage and mutation results, with no org.
  • A first-party JetBrains plugin. Tests, debugger, coverage and mutation results in IntelliJ without a third-party plugin in between.
  • A debugger that goes backwards. Replay a recorded run, or a debug log from your org, and step back to the line that set a value.
  • Checks against your own org. renmy compare --tests runs your tests in the org and locally and shows where they differ, with each side's governor usage.

Sources

aer facts, read on October 28, 2026:

renmy runtime facts: /parity, /faq (plans and what is not supported) and /docs. A correction to either column is welcome at contact@renmy.net.

Run your own suite on renmy runtime

The free tier runs a whole project with no test cap. Install it, run renmy test "*" in your Salesforce project, and compare the result with your org.