Architecture

Basecamp is not the sandbox

repository
    ↓
Basecamp environment bootstrap
    ↓
sandbox / CI worker / isolated runtime
    ↓
engineer or coding agent
    ↓
native project tools

The sandbox provider owns isolation and execution. Basecamp owns environment identity and preparation. This separation lets the same environment model fit managed coding sandboxes, programmable sandbox platforms, CI workers, local development, and self-hosted runtimes.

The lifecycle

native project files
  → fingerprint inputs locally
  → resolve basecamp.lock
  → synchronize only missing environment resources
  → verify and materialize immutable layers
  → activate the environment
  → use cargo / pnpm / go / uv / native tools

The lock sits above ecosystem locks

Cargo.lock, pnpm-lock.yaml, go.sum, and uv.lock remain authoritative for their ecosystems. Basecamp records their digests and locks the wider environment: runtimes, tools, native requirements, sources, and materialization rules.

Large bytes take the shortest trusted path

basecamp.lock
  ├─ language toolchains → trusted upstream distributions
  ├─ package sets → native package registries / Git
  ├─ explicitly published layers → Basecamp CAS
  └─ future AI / native assets → verified environment sources

Basecamp is direct-first. Large resources can come from trusted upstreams while Basecamp keeps the environment identity deterministic and verifiable.

Shared local store

Immutable materialized layers can be reused across projects through the Basecamp store. Project-local .basecamp contains activation state rather than a duplicate universe of package metadata.

Air-gapped environments

basecamp bundle pack exports the lock and materialized layers.bundle unpack restores them into an empty store without network access. This is the path for sandboxes whose workload phase intentionally cannot reach the network.