wandb/wandb: experiment tracking from a pip install to a self-managed server

What wandb/wandb solves, and who ends up using it

Training runs produce numbers that are hard to compare later. A script prints loss to stdout, someone copies a value into a spreadsheet, and three weeks later nobody can reconstruct which learning rate produced which curve. The wandb client attacks that by attaching a run object to your training loop: you declare a config dictionary up front, call run.log() during training, and the client ships metrics, config and files to a W&B project where runs are listed side by side.

The repository describes itself as a CLI and library for interacting with the Weights & Biases API, which is the honest framing. This is a client, not the whole platform. The people who get value from it are ML engineers and researchers already writing Python training loops who want comparison across runs without standing up their own metrics store. The README also points at framework integrations, so teams using PyTorch, TensorFlow, Keras or JAX can wire tracking in without hand-rolling callbacks. If you only ever run one experiment and read one number, the overhead is not worth it.

How the client, the run object and the server fit together

The mechanism is a run. wandb.init() opens a run against a project, and the object it returns is what you log to. Config is passed at init time and becomes the run's hyperparameter record. Calls to run.log() attach scalar values to steps. When the run ends, the client finishes the record and marks it complete, or marks it failed if an exception escaped.

The README's example uses a context manager for exactly that reason: the with block marks the run as finished on exit and failed on an exception. In a notebook the README suggests writing run = wandb.init() and calling run.finish() manually instead, because a notebook cell boundary does not map cleanly onto a with block.

Underneath, the package is not pure Python. The classifiers list Go and Rust alongside the Python versions, and the top-level repository entries include core/, xpu/ and parquet-rust-wrapper/ next to the wandb/ package. The dependency list in pyproject.toml includes protobuf, pydantic, xxhash and the OpenTelemetry SDK and OTLP HTTP exporter, which tells you the client is speaking structured protocols and batching telemetry rather than posting JSON per metric. What the client does not contain is the service it uploads to. Everything about storage, the web UI and collaboration lives on the W&B side.

Install wandb and log a first run

The README's quickstart starts with a single pip install. Nothing else is required to get the library onto the machine.

pip install wandb

An account is needed to store runs. The README says to sign up, create an API key at wandb.ai/settings, and store it securely, noting that keys can only be viewed once at creation. You can skip the login step because the client prompts for a key the first time you use it, but the CLI path exists:

wandb login

The console script is registered twice in pyproject.toml, as wandb and as wb, so both names invoke the same entry point. Once authenticated, this is the README's training example, trimmed to the tracking calls:

import wandb

project = "my-awesome-project"
config = {"epochs": 1337, "lr": 3e-4}

with wandb.init(project=project, config=config) as run:
    run.log({"accuracy": 0.9, "loss": 0.1})

What you should see: the client prints a run URL, and the README states that visiting wandb.ai/home shows the recorded metrics and how they changed during training, with each run object appearing in the Runs column under a generated name. The epochs and lr values you passed become the run's config rather than loose text in a log file.

The hosted control plane is the real dependency

The MIT licence covers the client. It does not give you a server. The README lays out three ways to run W&B itself: Multi-tenant Cloud, deployed in W&B's GCP account in GCP's North America regions; Dedicated Cloud, a single-tenant instance in W&B's AWS, GCP or Azure accounts with its own isolated network, compute and storage; and Self-Managed, deployed into your own cloud account or on-premises infrastructure.

That is the trade-off to weigh before adopting. If your runs cannot reach the internet, or your organisation will not send training metadata to a third party, you are on the Self-Managed path, which is an infrastructure project rather than a pip install. The client itself is the easy part. The README does not describe what Self-Managed deployment involves beyond the hosting documentation link, so treat the effort as unknown until you read that page.

There is also a version axis. The recent releases move quickly, from v0.28.2 on 2026-08-12 to v0.29.0 on 2026-08-26 and v0.30.0 on 2026-09-09, and the repository carries BREAKING.md plus CHANGELOG.unreleased.md at the top level. Fast minor releases with a dedicated breaking-changes file mean you should pin the client version in your training image rather than floating on latest.

Offline runs, sync and the failure mode nobody plans for

The most common wrong-tool case is a cluster with no egress. Training runs on an isolated node, the client cannot reach the service, and metrics either fail or accumulate locally. The search data shows people asking how to use wandb offline and how wandb sync works, which suggests this is a routine situation rather than an edge case. The README quickstart does not cover offline operation at all; it assumes a reachable service and a valid API key. If your environment needs offline collection, read the developer guide before you build the training image, because the answer changes how you launch runs and how you move results afterwards.

A second failure mode is quieter. Because the run context manager marks a run failed when an exception escapes, any crash inside the with block is recorded as a failed run, including crashes that have nothing to do with training. That is usually what you want. It stops being what you want when a notebook kernel restarts mid-cell and you have not called run.finish() yourself.

Finally, the API key handling deserves attention. The README warns that keys can only be viewed once and should go into a password manager or an environment variable. In shared CI, that means the key is a secret you rotate, not a config value you commit.

wandb alternatives and where the approach differs

The comparison people search for is wandb alternatives, and the substantive difference is architectural rather than feature-level. TensorBoard is the obvious reference point: it writes event files to a local directory that you point a server at. There is no account, no API key and no hosted control plane, and the trade-off is that comparison across machines and collaboration between people are things you assemble yourself.

MLflow takes a middle position. It ships a tracking server you run yourself as the default mode of operation, so the control plane is yours from the start rather than a hosting decision you make later. The wandb client inverts that: the default is a hosted service, and self-hosting is one of three documented options.

The practical question is not which has more features. It is where the run metadata is allowed to live, and who operates the thing that stores it. If the answer is "our own infrastructure, operated by us," wandb is still usable but you are paying the setup cost that MLflow or TensorBoard would have charged up front. If the answer is "we do not want to operate it," the wandb default is the shorter path.

Maintenance, licence and the upgrade cost you are signing up for

The repository is not archived, and the last push was on 2026-09-10, which is recent relative to the v0.30.0 release on 2026-09-09. Releases are landing roughly every two weeks across the versions listed, and the presence of CHANGELOG.unreleased.md means changes are staged in the tree before they ship. The project also states a policy on Python versions: it supports the minimum required Python version for at least six months after that version's end-of-life date, and increments the library's minor version when support is dropped. requires-python in pyproject.toml is currently >=3.10, and the classifiers list 3.10 through 3.14.

That policy has a direct cost. A minor version bump can be the signal that a Python version you depend on is gone, so an upgrade path that skips several minors needs the changelog read, not skimmed. Pinning the client and upgrading deliberately is cheaper than discovering the drop during a training run.

On licensing: the client is MIT. That is permissive and says nothing about the hosted service, its terms, or the server components you would deploy under the Self-Managed option. The repository does not state the licence of anything outside this client, so if your legal review depends on that, it is a question for W&B, not something to infer from the LICENSE file here.

Editorial conclusion

Adopt wandb if your team already runs training scripts in Python and wants metrics, config and artifacts recorded without building a tracking service. Do not adopt it if you cannot accept a hosted control plane, or if your runs have no network path and you have not planned around wandb offline mode. Verify three things before committing: which hosting option you are actually on, how wandb sync behaves for the offline directories you produce, and whether the MIT licence on the client covers the server components you intend to deploy.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wandb/wandb on GitHub