Replay Debugger is post-mortem: deploy, run, download the log, then step through what already happened. Nimbus is live: set a breakpoint, run, stop, inspect, the way every other language has been 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 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 are not running code, you are 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 it, re-run, and verify the fix, all in your editor, with no push to the org and no log-capture cycle.
Where the Replay Debugger is still the right tool
- 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 and you can't reproduce it from your laptop, but you can replay the log.
Both tools use the same VS Code UI
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, or the Replay extension parsing a log after the fact.
# Live debugging with Nimbus — start once, debug all tests
nimbus daemon
# Then in VS Code: set a breakpoint, F5 → "Nimbus: Debug Apex Test"When each one is the right tool
Replay is the right tool when the bug only reproduces against a real org (production data, a specific user context, platform features Nimbus doesn't fully implement yet). For everything else, the live cycle is shorter: edit, set a breakpoint, run, fix, re-run. The Replay cycle has more steps and they're all slower (push source, run, wait, download the log, open the log).
Try live debugging
Install Nimbus, set a breakpoint in any test, and press F5. The breakpoint hits without a deploy.