Comparison

Nimbus vs Apex Replay Debugger

The Apex Replay Debugger is Salesforce's offline debugger — it replays a debug log captured from a real org execution. Nimbus debugs live: set breakpoints, run a test, step through. Both end up looking similar in VS Code; the model underneath is different, and that changes what you can do.

Short version

Replay Debugger is post-mortem: deploy, run, download the log, then step through what already happened. Nimbus is live: breakpoint, run, stop, inspect — the way every other language has debugged for decades. Replay is the right tool when something only reproduces in a real org; Nimbus is the right tool the other 95% of the time.

How each one actually works

Apex Replay Debugger

You enable an Apex Debug Trace Flag on a user, run the code that fails, the platform emits a debug log, and you download it. You open the log in VS Code via the Salesforce extension and the Replay Debugger walks you through the recorded execution. You can step forward and back through the captured frames, see variables as they were at each point, and inspect call stacks. The log is a transcript — you're not running code, you're reading the trace.

Nimbus debugger

You set a breakpoint in your editor, run nimbus test, the interpreter pauses at your breakpoint, and you step through the actual execution. Step in / over / out, inspect any variable with full type information, evaluate expressions in scope, change a value and continue. There is no log; the debugger is attached to live execution.

What the live model changes

  • No "step backwards" because there's no need. You hit a breakpoint, look at state, decide what to inspect, continue. If you wanted to see earlier state, re-run with the earlier breakpoint set.
  • Evaluate expressions during the pause. Type account.Contacts.size() in the debug console, get an answer immediately. Replay can show you variables that were captured in the log; live debugging lets you ask new questions.
  • Conditional breakpoints work in real time. Break only when order.Amount > 10000. The engine evaluates the condition at every potential stop.
  • Edit and rerun without redeploying. Find the bug, fix the bug, hit re-run, verify the fix — all in your editor. No push to the org, no log capture cycle.

What Replay still owns

  • Production-only bugs. Something happens in real life that you can't reproduce locally. You enable a trace flag on the affected user, capture the log, replay it. Nimbus can't replay an org you don't have access to.
  • Platform-fidelity edge cases. Bugs that depend on specific governor-limit boundaries, async timing windows, or features Nimbus doesn't yet implement.
  • Post-incident analysis. The customer report says "yesterday at 14:32 the trigger errored on this record" — you weren't there, you can't reproduce it from your laptop. You can replay the log.

The same VS Code UI, both tools

Both debuggers speak the Debug Adapter Protocol, so the experience inside VS Code is familiar: breakpoint gutter, call stack panel, variables view, debug console. The difference is which engine is on the other end of the socket — Nimbus's interpreter for live debugging, the Replay extension parsing a log for post-mortem.

bash
# Live debugging with Nimbus — start once, debug all tests
nimbus daemon
# Then in VS Code: set a breakpoint, F5 → "Nimbus: Debug Apex Test"

The honest tradeoff

Replay is the right tool when the bug only reproduces against a real org — production data, specific user context, platform features Nimbus doesn't fully implement yet. For everything else, the live loop is shorter: edit, breakpoint, run, fix, re-run. The Replay loop has more steps and they're all slower (push source, run, wait, download log, open log).

Try live debugging

Install Nimbus, set a breakpoint in any test, press F5. The first time you hit a breakpoint without first deploying anything is the moment the workflow changes.