Five steps. No org connection required for the first four. Works on any standard SFDX project — point Nimbus at sfdx-project.json and go.
Prefer a longer walkthrough? See how to run Apex tests locally.
One-line install. Drops a single static binary into ~/.local/bin. No JVM, no Node runtime, no Docker. Linux, macOS (Intel + Apple Silicon), and Windows (native, no WSL required) all supported.
The install script verifies a SHA256 checksum and prints the binary path on success. Re-run it any time to upgrade.
On Windows, the first command below works in any shell — cmd.exe, Windows Terminal, even the Run dialog — by shelling into PowerShell directly. (PowerShell is built into every Windows install since Windows 7, so this is reliable.) The installer drops nimbus.exe in %LOCALAPPDATA%\Programs\Nimbus and appends it to your user PATH, no admin rights required. Scoop is an alternative if you already have it. To unlock Pro-tier speed, exclude ~/.nimbus from Microsoft Defender so it doesn't scan the embedded PostgreSQL data files on every test run (10×+ slowdown otherwise).
# macOS / Linux (one-liner)
curl -fsSL https://install.testnimbus.dev | sh
# Windows — works in cmd.exe, Windows Terminal, or any shell
powershell -c "irm https://install.testnimbus.dev/win | iex"
# Windows (already in PowerShell)
irm https://install.testnimbus.dev/win | iex
# Windows alternative: Scoop
scoop bucket add nimbus https://github.com/nimbus-solution/scoop-nimbus
scoop install nimbus
# Windows performance: exclude .nimbus from Defender
# (run once, in an elevated PowerShell)
Add-MpPreference -ExclusionPath "$env:USERPROFILE\.nimbus"
# Verify (any platform)
nimbus --versionBerlinBrew is a pre-configured starter project — a small fictional craft-brewery org with realistic Apex: pricing, loyalty, inventory, shipping callouts, field-level security, and a thorough test suite. Everything is wired up so you get a green, all-passing run in your terminal in under a minute.
Use it to verify your install works, to demo Nimbus to a teammate, or as a reference for what a healthy nimbus.properties and stubs/ setup looks like before you point Nimbus at your own codebase.
git clone https://github.com/nimbus-solution/berlinbrew-demo
cd berlinbrew-demo
nimbus test
# Expected: all green in under a secondRun nimbus init from your project root. Nimbus locates sfdx-project.json, creates a .nimbus/ directory, and starts an embedded PostgreSQL database scoped to this project.
nimbus doctor verifies the setup and surfaces any project-specific configuration nudges. If something's off it tells you exactly what.
cd path/to/your/sfdx-project
nimbus init
nimbus doctorRun a single class, a method, or all your tests. Patterns are case-insensitive glob-style. The first run may take a couple of seconds while Nimbus parses your Apex into an AST cache; subsequent runs land in milliseconds.
Add --coverage to see line coverage in your terminal. --json emits machine-readable output that AI agents and CI scripts can consume directly.
# Run all tests
nimbus test
# Run a single class
nimbus test AccountTriggerTest
# Run a single method
nimbus test AccountTriggerTest.testInsertCreatesContact
# Pattern match
nimbus test "*Selector*Test"
# With coverage
nimbus test --coverage
# Machine-readable output (for AI agents and CI)
nimbus test --jsonnimbus dev opens an interactive browser dashboard: test explorer, live results, schema browser, and an anonymous-Apex REPL. Especially nice if you'd rather not live in the terminal.
The dashboard runs entirely on your machine — no cloud service, no telemetry. It's a separate UI for the same local engine your tests use.
nimbus dev
# Opens http://localhost:8080 (or first free port)Nimbus runs your Apex against a synthesized schema by default — perfect for new projects and standalone library code. To run tests that depend on org-specific custom objects, custom metadata, or managed packages, sync your org's metadata into the local database.
Authenticate with sf first, then point Nimbus at the alias. Free re-syncs automatically before every nimbus test so you can't accidentally test against stale schema. Pro keeps state warm via the daemon — re-run sync manually when your org's schema changes.
# Authenticate via SF CLI (one time)
sf org login web --alias myorg
# Sync metadata into Nimbus
nimbus sync -o myorg
# Run tests against the synced schema
nimbus test -o myorg