Next.js containerControl planeNo repository execution
SECURITY / 05
Source confidentiality
Your source enters one job. Not another customer's runtime.
Synaptic must read an authorized checkout to build a code graph. We minimize that access by scope, time, credentials, network reach, and retained output—and we keep the web control plane out of repository execution entirely.
Source windowActive lease only
Analysis networkDisabled
Retained outputDerived graph
Hosted extraction / exact path
From repository to graph, with the access window closing behind it.
The hosted web application schedules work; a separate private worker handles repository material. Every stage narrows what the next process can see or do.
- LEASE / 01
Authorize one job
The worker claims a project-scoped job before it can request a repository credential. Stored provider secrets are sealed with AES-256-GCM, and the plaintext credential is released only against an active snapshot lease.
- FETCH / 02
Materialize one commit
Git accepts only HTTPS clone URLs on an explicit host allowlist and fetches one full, immutable commit digest. Hooks, submodules, LFS smudging, redirects, file/ext protocols, and interactive prompts are disabled.
- ISOLATE / 03
Remove network and secrets
Before analysis, the engine binary is re-verified by SHA-256. Bubblewrap starts it with a cleared environment, no repository credential, no external network interface, dropped capabilities, and separate user, PID, IPC, and UTS namespaces.
- ARTIFACT / 04
Export the derived graph
The worker opens the generated graph without following symlinks, validates and hashes owned bytes, then stages a mode-0600 copy outside the extractor mount. Raw repository files are not the uploaded artifact.
- SCRUB / 05
Delete the workspace
The per-job checkout, control files, and staged graph are recursively removed in the worker's final cleanup path after success, failure, cancellation, or completion-report loss.
Container architecture
Docker separates the services. Bubblewrap constrains the code-reading process.
The container is the deployment unit; the extractor is a second, narrower boundary inside the worker. They solve different parts of the problem.
Worker container · UID 65532Temporary checkoutCredential present only for Git fetch
Bubblewrap childSynaptic extractnetwork: none · env: cleared · caps: dropped
Private object storagegraph.jsonExact org / project / snapshot key
Small final images, immutable engine input
The web image runs a standalone Next.js build as non-root UID 1001. The worker base image is digest-pinned, runs as non-root UID 65532, and copies the public engine from a separate build context only after verifying its supplied SHA-256.
The production profile completes the boundary
Production requires a read-only root filesystem, ephemeral job storage, default-deny egress, resource limits, and private service paths. Bubblewrap is defense in depth; it is not a substitute for those host and orchestrator controls.
Tenant separation
Customer boundaries are checked before, during, and after analysis.
No single project identifier is trusted to establish access. Human authorization, database policy, worker leases, object scope, and graph-runtime identity each bind the request again.
Restricted by default
New projects require an explicit viewer, developer, or manager grant. Organization roles still cap each user's maximum authority.
Forced database isolation
The server checks membership and permission, then PostgreSQL forced row-level security independently evaluates transaction-local user and organization context.
Lease-bound worker access
Repository credentials, artifact grants, heartbeats, and completion reports are bound to the active project and snapshot lease. Cross-organization worker authorization failures are concealed as not found.
Exact artifact scope
A graph can be written only to its organization/project/snapshot object key with a short-lived signed HTTPS PUT grant that requires private access and encryption metadata.
Graph-only serving
The hosted runtime receives a verified read-only graph artifact—not repository source or Git credentials. User tokens stop at the platform and are never forwarded to the engine.
Content-blind operations
Worker logs use project and snapshot identifiers plus generic events. Clone URLs, source paths, credentials, signed URLs, graph contents, and child output are excluded by policy.
Runtime isolation is classified by trust level.
The production Kubernetes provider currently enforces one project per pod. Separate companies are not placed in the same organization-trust workload. Projects classified as mutually untrusted require a one-project hardened sandbox or microVM boundary whose RuntimeClass and attestation are qualified in the target environment.
Data handling / plain language
What we access, what we retain, and what we do not claim.
Security starts with an accurate description of the system. Synaptic is not “zero access”: the isolated worker reads the authorized commit so the engine can derive its graph.
- Temporarily processed
- The exact repository commit authorized for the active graph job.
- Retained
- A private derived graph artifact, graph metadata, and operational records required to serve and audit the project.
- Not sent to the graph runtime
- Repository files, provider credentials, Git configuration, and worker credentials.
- Excluded from logs
- Source and graph contents, clone and signed URLs, credentials, source paths, and extractor output.
Assurance register
Implemented controls are not the same as deployment claims.
This register separates safeguards present in the codebase from controls an operator must enforce and evidence in the production environment.
Enforced in application code
- Lease-gated source credentials
- Immutable commit verification
- Bubblewrap network isolation
- Credential clearing and job cleanup
- Forced RLS and restricted projects
- Scoped, private artifact grants
Required production controls
- Read-only worker root filesystem
- Ephemeral encrypted scratch storage
- Default-deny egress with exact exceptions
- CPU, memory, PID, and disk limits
- Private control-plane and object-store paths
- Non-superuser PostgreSQL application role
Must be qualified per environment
- Signed, SBOM-attested image provenance
- Cloud storage policy verification
- Sandbox RuntimeClass or microVM evidence
- Cross-tenant negative tests
- Failure, cleanup, and recovery drills
- Admission and network-policy validation
DEPLOYMENT / CONTROL
Need the entire system inside your boundary?
Self-host the control plane, workers, PostgreSQL tenant store, and graph runtime in infrastructure your team operates.