The ephemeral-workspace architecture that lets baselane learn a repo's profile without ever persisting your source.
baselane team · Apr 12, 2026 · 5 min read
Fit-gating a pack to a repo requires actually looking at the repo — its languages, its frameworks, its existing test and build commands. That's a reasonable thing to ask permission for, and it's also exactly the kind of access that makes a security team's job to ask hard questions about where that source code ends up. The honest answer we wanted to be able to give is: nowhere. Not in a database, not in a log, not in a training set. This post is about the architecture that makes that answer true rather than aspirational.
When a repo needs analyzing — at subscription time, or when its owner asks baselane to re-check fit for a pack — the analyzer checks the repo out into a workspace that exists only for the duration of that analysis. It runs the static checks that produce a profile: which languages appear and in what proportion, which frameworks are detectable from manifest and lockfiles, which commands the repo already declares for testing and building. Then the workspace is torn down. There is no step in between where the checked-out source is copied somewhere durable, because there is no durable location in the design for it to be copied to.
The only thing that survives analysis is the profile — a small, structured record of what was detected, not the code that produced it:
{
"languages": ["typescript"],
"frameworks": ["vitest", "node:http"],
"commands": { "test": "pnpm -r test", "typecheck": "tsc --noEmit" }
}That's the artifact fit-gating actually reasons over. It's enough to decide whether a Vitest-based test-loop pack should be offered to this repo, and nowhere near enough to reconstruct a single line of the repo's actual source. The gap between "we looked at your code" and "we kept a copy of your code" is the entire point of the architecture.
A privacy policy that says "we don't retain your source" is a promise a company makes. An architecture where there's no code path that writes source to a persistent store is a constraint the system enforces regardless of what anyone intends. We wanted the second kind, because the first kind depends on every future engineer remembering not to add a convenient caching layer that happens to also cache the checkout. If there's no durable store the analyzer can write source into, that mistake isn't available to make.
This is also why fit-gating stays fast at scale: the profile is small and cheap to store and query, while the expensive, sensitive part — actually reading the source — happens once, in a workspace that's already gone by the time anyone could ask where it went.