I've wanted easy trunk-based development for Salesforce for years.
Short-lived branches, frequent merges, small pull requests, and CI fast enough that developers aren't afraid to commit. The same practices that engineering teams use everywhere else.
Every time I tried to make it work, I hit the same wall: Apex tests require an org.
That single dependency turns every validation run into an infrastructure problem. Before a test can execute, you need authentication, environment provisioning, metadata deployment, test execution, and cleanup. The result is feedback loops measured in minutes instead of seconds.
I got tired of waiting and built Nimbus, a local Apex runtime that executes Apex tests without an org.
This is what I learned while trying to make trunk-based development actually work for Salesforce.
Why trunk-based development is hard in Salesforce
Trunk-based development depends on fast feedback. If validation takes seconds, developers make smaller changes, merge more frequently, and keep branches short-lived. If validation takes fifteen minutes, behavior changes. Pull requests get larger, unrelated work gets batched together, and validation stops happening continuously because validation itself becomes expensive.
Salesforce has always had a structural challenge here because Apex only runs inside Salesforce.
A typical validation pipeline looks something like this:
sf org login jwt
sf org create scratch
sf project deploy start
sf apex run test
sf org delete scratch
There is nothing inherently wrong with these steps. The problem is that most of them have nothing to do with testing. They're infrastructure management. The actual validation of business logic is only one part of the process.
The longer I worked with Salesforce CI, the more obvious it became that the bottleneck wasn't Apex itself. The bottleneck was everything required to create an environment where Apex could run.
The solutions I tried first
Before building a local runtime, I tried solving the problem the same way most Salesforce teams do.
If Apex tests require an org, the obvious answer is to make org creation faster. Scratch org pools, sandbox pools, pre-provisioned environments, and reusable test orgs all sound reasonable on paper.
In practice, I found myself building infrastructure whose only purpose was making test execution possible.
A scratch org pool still needs a Dev Hub. It still needs authentication. It still needs lifecycle management. Someone has to create orgs, monitor capacity, replenish exhausted pools, rotate certificates, and investigate failures when something inevitably goes wrong.
Sandbox pools introduce a different set of problems. Now you're dealing with shared state, refresh cycles, environment drift, and coordination between teams. The CI pipeline becomes responsible not only for validating code, but also for managing a fleet of Salesforce environments.
I spent a lot of time trying to make these approaches work. They helped, but they never solved the underlying problem.
The dependency was still there.
Whether the org was created on demand, pulled from a pool, or shared across teams, every test run still depended on Salesforce infrastructure existing before validation could begin.
Eventually I realized I was optimizing around the dependency instead of removing it.
If trunk-based development was the goal, I didn't need faster orgs.
I needed no orgs.
The dependency I wanted to remove
When I started building Nimbus, the goal wasn't to create a faster CI pipeline, but the goal was simpler.
I wanted to run Apex tests without needing Salesforce infrastructure.
That meant solving many of the same problems I described in a previous article: parsing Apex, executing Apex code locally, supporting DML and SOQL, reproducing trigger behavior, implementing test isolation, and matching Salesforce runtime semantics.
A local runtime that behaves differently from Salesforce is worse than useless. If local tests pass and org tests fail, developers stop trusting the tool. Every design decision ultimately came down to one question:
"Does this behave the same way Salesforce behaves?"
Because if the answer was no, nothing else mattered.
What changes when Apex runs locally
Once tests no longer require an org, something interesting happens.
Large parts of the pipeline disappear.
The GitHub Actions workflow for one of my demo projects looks like this:
name: Apex Tests
on:
pull_request:
branches: [main]
jobs:
apex-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Nimbus
run: curl -fsSL https://install.testnimbus.dev | sh
- name: Run Apex tests
run: |
nimbus test "*" \
--coverage --coverage-report coverage.xml \
--results-xml results.xml
No Dev Hub.
No scratch org.
No source deployment.
No org cleanup.
Nimbus produces JUnit and Cobertura reports, so existing tooling still works. Coverage gates, pull request checks, SonarQube analysis, and test reporting continue operating exactly as before.
The difference is that the tests execute directly against the source code in the repository rather than a deployed copy inside an org.
The repository becomes the source of truth
This ended up being one of the most important shifts.
Traditional Salesforce development often treats the org as the thing being tested. Code is deployed into an environment, and that environment decides whether the code works.
In most software ecosystems, the repository itself is the source of truth. The code in Git is the thing being compiled, tested, and validated.
A local runtime pushes Salesforce closer to that model.
Nimbus reads the SFDX project directly from disk and executes the code that's actually committed to source control. There is no deployment step sitting between the code and the test run.
The org stops being a development dependency and starts becoming a deployment target.
That sounds like a subtle distinction, but it changes how the workflow feels.
What changed in the inner loop
The biggest difference wasn't CI.
It was how I wrote code.
Before, a typical iteration looked like this:
- Edit Apex
- Deploy to an org
- Wait
- Run tests
- Wait
- Fix the bug
- Repeat
With a local runtime, the loop becomes:
- Edit Apex
- Run tests
- Fix the bug
- Repeat
The difference isn't just speed.
Developer behavior changes when feedback becomes cheap.
You run tests more often. You refactor more confidently. You make smaller changes and catch mistakes earlier. Validation stops being something you do at the end of a feature because validation is no longer expensive.
The workflow starts looking much closer to what developers in other ecosystems have had for years.
What changed in CI
The CI improvements were almost a side effect of solving the local testing problem.
One of the BerlinBrew demo runs currently executes 157 tests with over 93% coverage. The GitHub Actions workflow completes in about 30 seconds, and the actual Apex execution takes roughly one second. Most of the remaining time comes from GitHub Actions startup overhead.
More importantly, the pipeline becomes dramatically simpler.
There are no org credentials to manage. There are no scratch org limits to monitor. There are no deployment failures unrelated to the code being tested.
The build focuses on validating behavior.
That's what CI should be doing in the first place.
What I learned
A few things surprised me during this journey.
The first is that most Salesforce CI time is not spent running tests. It's spent preparing an environment capable of running tests.
The second is that developers adapt their workflow to the speed of feedback. Fast feedback encourages small pull requests. Slow feedback encourages batching.
The third is that many of the challenges people associate with trunk-based development in Salesforce aren't really process problems.
Most teams already understand the benefits of smaller changes and more frequent merges. The difficult part is making validation fast enough that those practices become natural.
And finally, I learned that scratch orgs are often doing two completely different jobs at once.
They're acting as deployment targets and test environments.
Once those responsibilities are separated, a lot of complexity disappears.
Does this replace Salesforce?
No.
There are still platform features that require a real org. Nimbus is not trying to replace Salesforce.
It's trying to remove Salesforce from the parts of the development loop where Salesforce isn't adding value.
For many Apex tests, that turns out to be a much larger portion of the workflow than I originally expected.
Try it
Nimbus runs directly against existing SFDX projects.
curl -fsSL https://install.testnimbus.dev | sh
nimbus test
If you've ever wanted Salesforce development to feel more like every other modern software stack, this is the closest thing you will find.
Top comments (0)