Leave no trace (in the cloud): W&B Weave locally in three commands
If you want the shortest path from “curious about Weave” to “looking at a trace," well, you're in luck
Last updated: August 13, 2026
If Docker is running on your machine, you’re three commands away from a local Weave instance. No cloud, no Kubernetes cluster to provision, no container registry to configure. The traces you send stay on your laptop.
If you want the shortest path from “curious about Weave” to “looking at a trace," well, you're in luck.
What you’re actually running
wsm (W&B Server Manager) creates a small Kubernetes cluster inside Docker using kind, then installs the full self-managed W&B stack into it: the W&B app, Weave, and the databases behind them (ClickHouse, MySQL, Redis, Kafka, an object store). This isn't a stripped-down demo container. It's the same stack an on-prem install runs, shrunk to laptop size, which means the trace you send at the end lands in a ClickHouse pod on your machine instead of a SaaS backend.
Before you start
You need about 10 minutes and the following:
- An amd64 (x86_64) machine. The operator image is amd64-only today (multi-arch is on the roadmap), so it won't run on an Apple Silicon Mac's local cluster. On Apple Silicon, point `wsm` at a remote amd64 machine or VM instead.
- Docker, or another Docker-compatible runtime
- wsm and kind on your PATH
- kubectl, if you want to watch the pods come up
- Ports 8080 and 8443 free
The three commands
wsm cluster create --cluster-name wandbwsm deploy-v2 operator --context kind-wandbwsm deploy-v2 wandb deploy --context kind-wandb --wandb-version 0.82.2
The first creates a kind cluster named wandb inside Docker. The second installs the W&B operator and its supporting pieces. The third tells the operator to install W&B Server itself, Weave included.
Version 0.82.2 is current as I write this; swap in whatever the latest release is.
💡
Watch it come up
kubectl get pods --namespace wandb --watch
The first pull is the slow part, a few minutes depending on your connection. You'll see the app, Weave, and the databases flip to `Running` one by one. When they have, open:
Create a local account, then generate an API key from the user settings on this instance. **A key from wandb.ai won't work here** - this server has its own users and doesn't know the cloud exists. (trust me i had a slight moment of forgetfulness and tried solving this for longer than I would like to admit)
Send a trace that stays local
python -m pip install weaveexport WANDB_BASE_URL = http://localhost:8080
Create local_weave.py
import weaveweave.init("local-weave-demo")# Weave records this function's inputs and outputs as a trace@weave.op()def inspect_message(message:str)-> dict[str, str]:return{"message":message,"storage":"my local W&B server",}
Now run it
Weave prints a trace link. Open it, and there's your call - input and output stored by the W&B Server on the cluster you created two minutes ago. The example doesn't hit an external model API, so nothing about it left your machine.
Now tear it down
When you need more than a laptop
These three commands pull charts and images from the public registries, which is exactly right for a local test and exactly wrong for the environments wsm was really built for. If your cluster is air-gapped, or every image has to come from a registry you control, the on-prem deployment guide covers that path: private registry, mirroring, the manifest handoff, all of it.
For a laptop, skip all that. Three commands.
Try it yourself
Everything linked above, in one place:
- wsm releases — grab the latest binary for your platform
- wandb/wsm on GitHub — source, docs, and the on-prem / air-gapped deployment guide
Add a comment
Iterate on AI agents and models faster. Try Weights & Biases today.