Quickstart

A passing Apex test
in 60 seconds

Five steps, and the first four need no org connection. Nimbus works on any standard SFDX project; point it at sfdx-project.json.

Prefer a longer walkthrough? See how to run Apex tests locally.

1. Install

The install is one line. It drops a single static binary into /usr/local/bin, or ~/.local/bin when that is not writable. There is no JVM, Node runtime, or Docker. Linux, macOS (Intel + Apple Silicon), and Windows (native, no WSL required) are all supported.

The install script prints the binary path on success and, when the directory is not already on your PATH, adds one export line to your shell profile and says so (NIMBUS_NO_MODIFY_PATH=1 to skip that). 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. For 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).

bash
# 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 --version

Try the starter project

BerlinBrew 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.

bash
git clone https://github.com/nimbus-solution/berlinbrew-demo
cd berlinbrew-demo
nimbus test

# Expected: all green in under a second

2. Initialize the project

Run 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.

bash
cd path/to/your/sfdx-project
nimbus init
nimbus doctor

3. Run your first test

Run 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.

bash
# 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 --json

4. Open the dashboard

nimbus 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, with no cloud service and no telemetry. It's a separate UI for the same local engine your tests use.

bash
nimbus dev
# Opens http://localhost:8080 (or first free port)

5. Connect an org (optional)

Nimbus runs your Apex against a synthesized schema by default, which suits 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.

bash
# 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

Where to go next