The Nimbus daemon pre-parses your entire codebase, loads flows, record types, custom metadata, and labels once at startup — and holds them in memory. Every test run after that starts in milliseconds, not seconds.
Requires a Pro license. Free-tier users can still run tests from the CLI without the daemon.
Every time you run nimbus test without the daemon, Nimbus reads your project from scratch: parses every Apex file, loads every flow, reads every record type, resolves all labels and custom metadata. On a large project that work takes 10–12 seconds before a single test executes.
Multiply that by every invocation in a TDD session and you lose minutes per hour to startup overhead — work that produces no new information, just the same warm state you had at the end of the last run.
The daemon eliminates that overhead. It starts once, loads everything, and stays running. From that point forward, every test run — CLI or VS Code — connects to the already-warm daemon and starts executing immediately.
When nimbus daemon start runs, it works through your project systematically: flows first (fast to parse, needed for trigger evaluation), then record types and labels, then custom metadata, then full Apex parsing, and finally builds the test class index.
The warm-up output shows exactly what was loaded and how long each step took. Once "Cache warm-up complete" appears, the daemon is accepting connections and every subsequent run pays none of these costs.
On a large project — 600 Apex files, 65 flows, 340 labels — total warm-up is around 12 seconds. A smaller project warms up proportionally faster.
The daemon holds a complete, ready-to-execute image of your project. Nothing is re-read from disk between runs.
All Apex files are tokenized, parsed, and stored as abstract syntax trees in memory. Each test run receives the parsed program directly — no file I/O, no parsing delay.
Record-triggered flows, autolaunched flows, and subflows are parsed and registered at startup. When a DML fires a flow, the daemon dispatches it from the already-loaded registry.
Custom labels, record types, custom metadata type records, field sets, child relationships, and validation rules are loaded into memory. SOQL against these types hits the in-memory cache.
The embedded PostgreSQL instance stays running. The daemon holds an open connection pool, so each test run gets a connection immediately rather than waiting for the database to start.
The daemon watches your project for file changes. When you save an Apex file, the daemon re-parses it in the background and updates the AST cache — so the next test run sees your latest code without any manual restart.
Metadata changes — new custom metadata records, updated flows — are picked up the same way. The daemon stays in sync with your working directory throughout a development session.
If you need a clean slate — new schema synced, schema changes applied — restart the daemon with nimbus daemon stop and nimbus daemon start. The warm-up runs once and you're back to instant.
You don't need to run nimbus daemon startmanually. The VS Code extension starts the daemon automatically when it detects a Pro license — the first time you open a Salesforce project, the warm-up runs once in the background.
The status bar shows a Nimbus indicator. When the daemon is connected and ready, the indicator is solid. If it shows a slash, the daemon isn't running — use Nimbus: Restart Daemon from the command palette and check the Nimbus output channel for details.
All VS Code features — inline test results, CodeLens buttons, coverage gutters, trace viewer, governor limits view — communicate with the daemon over a local JSON-RPC connection. The editor never starts a new process per run.
Start the daemon once per project session. It runs as a detached background process — you can close your terminal and it keeps running. Use nimbus daemon status to confirm it's alive and see what's loaded.
Pass --clean to drop and recreate the database before starting — useful after a schema sync or when you want a completely fresh state.
# Start the daemon (detaches to background)
nimbus daemon start
# Start with a clean database
nimbus daemon start --clean
# Check status — uptime, connections, files loaded
nimbus daemon status
# Stop the daemon
nimbus daemon stopThe daemon is included in Nimbus Pro. Start it once, and every CLI run and VS Code test connects to the already-warm process — no cold start, no metadata loading, no database startup delay.