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 means actually looking at it: its languages, frameworks, existing test and build commands. That's a reasonable thing to ask permission for. It's also exactly the kind of access that makes a security team ask hard questions about where that source code ends up. The honest answer we wanted to give is: nowhere. Not in a database, not in a log, not in a training set. This post explains the architecture that makes that true.
When a repo needs analyzing (at subscription time, or when its owner asks baselane to re-check fit for a pack), the analyzer checks it 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's no step where the checked-out source gets copied somewhere durable. There's nowhere in the design for it to go.
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. That's the whole reason this architecture exists: so we can look without keeping a copy.
A privacy policy that says "we don't retain your source" is a promise a company makes. An architecture with 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. 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 to write into, that mistake just isn't possible.
This is also why fit-gating stays fast at scale. The profile is small and cheap to store and query. Reading the source, the expensive and sensitive part, happens once, in a workspace that's already gone by the time anyone could ask where it went.