Documentation · Basecamp

Start here

Install Basecamp.
Run basecamp init once in an existing project.
Commit the generated basecamp.lock with the project.
On another machine, CI job, or sandbox with the same host triple, run basecamp sync.
Use basecamp shell when you want an interactive activated shell.
Run the project's normal build/test commands.

Core commands

Command	Purpose
`basecamp init`	Detect the project, clarify missing choices, create the first lock, and sync it.
`basecamp sync`	Reproduce the existing lock without changing it.
`basecamp update`	Re-resolve the project, update the lock, and sync the result.
`basecamp shell`	Enter the synchronized environment.
`basecamp status`	Inspect lock, project inputs, and materialized layers.
`basecamp doctor`	Diagnose environment problems.
`basecamp clean`	Remove project-local environment state; `--cache` also removes the shared store.
`basecamp bundle`	Pack or unpack a completely offline environment.

basecamp.lock is not another package lock

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

Project stacks

Rust / Cargo — available today.
pnpm / npm — planned.
Go — planned.
Python / uv — planned.

Where software comes from

Basecamp is direct-first: trusted upstream distributions and native registries are used when possible. Basecamp CAS is an optional path for explicitly published, content-addressed layers. The current control plane does not schedule remote builders. Air-gapped environments use bundles.

Automation

Direct integrations can resolve environment locks through OpenAPI.