CargoAvailable
Detects
Cargo.tomlCargo.lockUse
xcap fetchxcap run -- cargo buildResult
Open guide →Vendored crates, lockfile, Cargo source config, offline local build.
Software supply for development environments
One workflow for the dependencies, tools, and runtimes your project needs.
Run the command you already use. CapWarp prepares what the project is missing, delivers it to the current environment, and keeps the final build local.
prepare the project
xcap fetchrun your normal command
xcap run -- cargo buildAvailable today: Cargo ·Target experience defined for pnpm, Go, Python, binaries, toolchains, models, and agent tools.
Start with your stack
The command stays familiar. The preparation moves out of your environment.
Each integration follows the same product model: detect the project, prepare the missing capability remotely, deliver a reusable result, then run the ecosystem's native command.
pnpm / npmPlanned
Detects
package.jsonpnpm-lock.yamlTarget UX
xcap fetchxcap run -- pnpm buildResult
Open guide →Prepared package store and lock-preserving dependency materialization.
GoPlanned
Detects
go.modgo.sumTarget UX
xcap fetchxcap run -- go build ./...Result
Open guide →Resolved module cache and reproducible build inputs for the selected Go version.
Python / uvPlanned
Detects
pyproject.tomluv.lockTarget UX
xcap fetchxcap run -- uv run pytestResult
Open guide →Wheelhouse or prepared environment artifact matched to Python ABI and platform.
Binary toolsPlanned
Examples
ffmpegprotocTarget UX
xcap get ffmpegxcap get protocResult
See capability →Verified platform-specific binaries without baking them into every environment.
Models & agent toolsIn design
Examples
modelMCPTarget UX
xcap get model:...xcap get mcp:...Result
See capability →Model artifacts or tool bindings resolved against runtime and policy constraints.
Capability map
The system is designed to move far more than package dependencies.
Every capability class uses the same control-plane concepts: request identity, provider resolution, execution, events, cache, artifact or service delivery, and verification in the target environment.
Capability classExamplesMaturity
Package graphsCargo · pnpm/npm · Bun · Deno · Go modules · Python/uv/pip · Maven · Gradle · NuGetAvailableCargo today; others expand through providers
System packagesapt · apk · Homebrew · system libraries · headers · pkg-config inputsPlannedOS-level materialization
Tools & binariesprotoc · ffmpeg · chromium · git · jq · language servers · GitHub Releases · static binariesPlannedbinary provider family
ToolchainsRust · LLVM · GCC · Node · Go · Python · Java · .NET · Android SDK · cross-compilersPlannedruntime and compiler supply
SDKs & native dependenciesOpenSSL · CUDA · ROCm · protobuf · system SDKs · vendor SDKs · C/C++ librariesPlannedplatform-aware resolution
Containers & imagesOCI images · layers · devcontainers · build roots · runtime imagesPlannedimage and rootfs providers
Models & AI assetsmodel weights · tokenizers · adapters · embeddings · indexes · inference runtimesPlannedmodel artifact providers
Data & build assetsdatasets · generated code · schemas · browser bundles · firmware · reference assetsPlannedcontent-addressed asset delivery
MCP & agent toolsMCP servers · tool plugins · agent skills · runtime adapters · browser/computer toolsIn designagent-facing capability layer
Remote servicesAPIs · databases · queues · object stores · browsers · GPU workers · remote executionIn designservice-backed capabilities
Execution environmentsephemeral sandboxes · Firecracker VMs · builder pools · CI workers · GPU runtimesLong-termexecution fabric
Environment boundaries
Keep environments small. Acquire the heavy parts only when they are needed.
Local development
Resolve once elsewhere, consume the resulting artifact locally, and keep the final command native to the developer machine.
CI and ephemeral workers
A job starts with a minimal image, asks for the capability set it needs, and avoids repeating expensive preparation work.
Sandboxes
Network-restricted or disposable environments can receive prepared artifacts instead of installing an entire development stack.
Agent runtimes
An agent can detect a missing capability, request it through a stable protocol, verify the result, and resume the original task.
Current implementation
The first production path is Cargo. The system around it is already generic.
Today the Cargo provider turns a manifest and optional lockfile into a content-addressed, offline-ready artifact. The same control-plane interfaces are used for providers, execution backends, storage, jobs, and events.
Read the architecture →InputCargo.toml + Cargo.lock
ControlRequest · cache · singleflight
ExecuteGitHub Actions today
ArtifactVendored dependencies + config
Consumecargo build --offline
Stable protocol
Provider-specific inputs. Infrastructure-independent jobs.
Providers decide how a capability is resolved and materialized. Clients keep using the same request, job, event, and artifact model even when execution moves from GitHub Actions to a dedicated builder fleet.
{
"provider": "cargo",
"runtime": "1.95.0",
"target": "x86_64-unknown-linux-gnu",
"inputs": {
"manifest": "...",
"lockfile": "..."
}
}Machine-readable by default
The documentation is also an interface.
Human documentation and machine-readable contracts live under the same origin, so tools and agents can discover the API without scraping marketing copy.