Run and debug Salesforce Apex tests without connecting to an org. Gutter run icons, a native debug session, and a Nimbus tool window, driven by the same local runtime the CLI uses.
IntelliJ IDEA Community and Ultimate, and every other JetBrains IDE from 2024.2 forward.
Every discovered @IsTest class and method gets a clickable run icon in the editor gutter — the IDE's own test affordance, not a bolted-on panel. Run the class, run the method, debug it, or open its trace. After a run the icon carries the last outcome, and results stream into the standard IntelliJ test runner tree with per-method timings.
Code lenses sit above the same declarations with the full command set: Run, Debug, Coverage, Trace, Bench, and Mutate. Prefer a saved entry point? Create a Nimbus Apex Test run configuration for a glob pattern or an explicit Class.method list.
Debugging is a real IntelliJ debug session. Set line breakpoints in .cls and .trigger files, hit Debug, and step over, into, and out while inspecting variables and the call stack. The local runtime is executing your code — this is live stepping, not a replayed debug log.
The Nimbus tool window docks on the right with six tabs: Tests, Coverage, History, Schema, Releases, and Governor. Double-click a test to jump to source, or run and debug the selection from the toolbar.
Run a coverage pass, snapshot it with Set Coverage Baseline, then toggle the delta overlay to see which lines your change covered — and which it stopped covering — in the gutter.
The dependency graph, execution traces, Trends, and run diffs open in embedded browser panels — the same views the VSCode extension ships, rendered inside the IDE.
Native Apex and SOQL live templates: tm for an @IsTest method, soqlf for a bulk-safe SOQL for-loop, bulkt for a 200-record data block. Tab to expand, Tab through the placeholders.
Nothing about the Apex engine is reimplemented for JetBrains. The plugin drives the two backends that ship with the CLI: nimbus lsp for editing intelligence and nimbus daemon for the runtime — test discovery, running, debugging, coverage, traces, history, schema, and governor limits.
Editor intelligence arrives through LSP4IJ, so completion, hover, navigation, rename, semantic tokens, call hierarchy, diagnostics, quick-fixes, code lenses, and inlay hints are the language server's — identical to what the VSCode extension consumes. A fix in the server lands in both editors at once.
LSP4IJ works in Community editions as well as the paid ones, so nothing on this page depends on an Ultimate license. The gutter run icons take a separate path entirely — they read the daemon's discovery index directly, with no PSI and no language registration, which is why they coexist with whatever else already claims Apex files in your IDE.
Read what the server does on the language server page, or compare the editor surface with the VSCode extension.
Illuminated Cloud made IntelliJ a serious Salesforce IDE, and Nimbus does not replace it. Keep it for editing, org metadata, and deployment. Nimbus adds the one thing an org-backed workflow cannot: a local Apex runtime, so the test loop stops round-tripping to a sandbox.
Both plugins read the same sfdx-project.json and the same source tree. No project conversion, no second checkout, no exclusive lock on .cls files.
Read the how-to for the full side-by-side setup.
The plugin drives the nimbus binary, so it has to be on your PATH.
curl -fsSL https://install.testnimbus.dev | shIn Settings → Plugins → Marketplace, install Nimbus — Local Apex Runtime. The Marketplace resolves the LSP4IJ dependency for you.
On first open the plugin starts the daemon and warms the language server. Tests appear in the tool window and run icons appear in the gutter. If the CLI is not found, point the plugin at it in Settings → Tools → Nimbus.
Settings are stored per project under Settings → Tools → Nimbus: binary path, parallel workers, whether the language server runs, coverage collection and gutter icons, validate-on-save, inline timings, inline governor usage, and auto-run on open or save. The full table is in the settings reference.
Gutter run icons, a native debug session, coverage in the editor, and the full Nimbus tool window — with no org connection anywhere in the loop.