Building an Ephemeral Code Review Pipeline with Zero Data Retention
How we process pull requests in temporary worker RAM and wipe runtime state instantly, ensuring customer code is never saved to disk or used for model training.
Security & Compliance
Platform Security & Cryptography
The Core Prerequisite: Absolute Code Privacy
When evaluating developer tools, software engineering leaders and CISOs have one non-negotiable question: "What happens to our source code when your bot scans it?"
Too many SaaS platforms store repositories on persistent cloud storage, retain logs containing proprietary function logic, or feed customer source code into generalized model training corpuses. In regulated industries—fintech, healthcare, and enterprise infrastructure—this is an immediate deal-breaker.
From our first line of code, GitCaptain was engineered around a simple premise: your source code is analyzed strictly in temporary memory and disappears the moment the review is posted.
GitCaptain operates on ephemeral Linux worker containers. We never write repository source code to persistent disk, and we have zero access to your code once the check run completes.
Lifecycle of an Ephemeral Review Run
Here is the step-by-step cryptographic and compute lifecycle of a GitCaptain review run:
1. GitHub sends a webhook payload over TLS 1.3 signed with an HMAC SHA-256 secret. We verify the signature before accepting the event.
2. An isolated Linux container mounts an in-memory `tmpfs` volume in RAM. The pull request diff and syntax trees are loaded solely into this volatile memory buffer.
3. Tree-sitter evaluates the syntax trees, computes cyclomatic metrics, and queries our AI gateway with isolated code subtrees.
4. Structured review comments are dispatched back to GitHub via authenticated API calls.
5. The `tmpfs` RAM volume is unmounted and overwritten, the container is destroyed, and all temporary runtime allocations are wiped clean.
// Ephemeral container sandbox lifecycle
export async function executeEphemeralReview(
payload: GitHubWebhookPayload
): Promise<void> {
const sandbox = await allocateMemorySandbox({ ramLimitMb: 512 });
try {
// Ingest diff strictly into RAM buffer (tmpfs)
const diffBuffer = await fetchSecureDiff(payload.diffUrl);
const analysis = await sandbox.runASTAnalysis(diffBuffer);
// Post comments back to GitHub API
await postReviewAnnotations(payload.pullRequestId, analysis.comments);
} finally {
// Explicit, deterministic memory wipe and sandbox destruction
await sandbox.zeroMemory();
await sandbox.destroy();
}
}Zero Plaintext Key Storage at Rest
For developers who choose to supply their own LLM API keys via our `/apis` vault, keys are encrypted using AES-256-GCM with envelope encryption. Keys are decrypted exclusively in worker RAM during active requests and never appear in application logs or crash dumps.
This guarantees that even in the theoretical event of a database compromise, no third-party keys or customer source code can be extracted.
Key Architectural Takeaways
- Stateless ephemeral RAM sandboxes ensure customer source code never touches persistent disks.
- TLS 1.3 encryption in transit with HMAC SHA-256 webhook authenticity checks.
- Zero model training on customer code—private repositories stay private.
- AES-256-GCM envelope encryption for all user-supplied provider API keys.
Read Next from Engineering
More deep dives on compilers, architecture, and code quality.
Why ASTs Beat Raw LLM Prompts for Code Review
Feeding raw files directly to generative models results in hallucinated warnings and token bloat. Here is how structured syntax trees deliver 10x faster reviews with deterministic accuracy.
Why Isolated Diffs Make Bad Code Reviews
Most CI bots only inspect the 10 lines modified in a pull request. Here is how full-codebase dependency graphs catch breaking changes that happen three directories away.