Command Palette

Search for a command to run…

ZarynZaryn
Core concepts·4 min read

What is zev

What zev and Zaryn are, what they are made of, and what they can do.

zev is a content-addressed engine for code, data, and machine learning artifacts. At its core it stores every object — a file, a tree, a commit, a dataset shard, a model checkpoint — by the hash of its own content, and builds a growing set of capabilities on top of that single idea: tracking history, understanding what actually changed, syncing large files efficiently, running CI that skips redundant work, and following the full lineage of a model from raw data to a published result. It was designed from the start to be extended. Version history is the foundation, not the ceiling — the same engine that stores your commits also tracks ML experiments, merges model weights, detects metric drift, verifies reproducibility, and notarizes results on-chain. New capabilities are added as new commands and IPLD node types on the same object store, not as separate systems bolted on the side. ## What zev is made of zev is three cooperating pieces, each independently built and tested before being wired together: - **`zev`** — the command-line engine. Installed locally, it manages a working directory, a local content-addressed object store under `.zev/`, and talks to a remote server over HTTP, SSH, or IPFS. - **`zev-api`** — the server. Written in Zig, it stores repository objects, manifests, and metadata in PostgreSQL and on disk, exposes a JSON HTTP API, and enforces authentication and access control. - **`zev-ci`** — a continuous integration service that runs pipelines in isolated Docker containers, triggered by pushes to `zev-api`, and skips steps whose inputs it has already seen succeed. ## Zaryn: the web platform **Zaryn** ([zaryn.xyz](https://zaryn.xyz)) is the hosted platform built on top of this engine — where repositories, organizations, issues, pull requests, and people actually live and are browsed. Every repository, commit, and pinned file on Zaryn is addressable by the same content hashes the `zev` CLI produces locally, so what you see on the web is a direct view into the same object store, not a separate copy. Zaryn adds: - Repositories for code, ML models, datasets, agents, and network topology definitions, each with issues, pull requests, and a contributor graph - Organizations with their own cryptographic identity, so commits endorsed on an org's behalf can be verified independently of any one member - Real-time messaging and notifications between users - IPFS pinning with signed attestations, so a pinned file's authenticity can be verified offline - A public activity feed and full-text semantic search across commits and repositories - Deployments to any Kubernetes cluster or Docker host through `zev-agent`: signed builds only, canary rollouts gated on Prometheus metrics, secrets from Vault and cloud secrets managers, releases across targets in waves, GitOps export and sync, project roles, an audit log and single sign-on for organizations — usable by people, CI and AI agents (`zev-deploy`, MCP) ## Core capabilities **Content addressing throughout.** Every object is identified by the hash of its own content. Two identical files anywhere in a repository's history occupy the same object, automatically. **Chunking for large files.** Large files are split into content-defined chunks (see [Content-defined chunking](/docs/en/chunking)), so a small edit only requires transferring the bytes that actually changed. **AST-aware diffing for code.** zev parses Zig source with a real AST parser and reports structural changes — function renames, signature changes, body changes — not just line-based text differences (see [Semantic (AST) diffing](/docs/en/semantic-diff)). **ML experiment and dataset tracking.** `zev experiment`, `zev dataset`, and `zev lineage` track hypotheses, dataset splits, shard assignments, and the full provenance graph connecting a model back to the data and scripts it came from. **Model weight diffing and merging.** `zev wdiff` compares tensors directly inside `.safetensors`, PyTorch, and NumPy files. `zev merge-weights` merges checkpoints with averaging, weighted interpolation, spherical interpolation (SLERP), or TIES-merging. **Drift, regression, and reproducibility.** `zev drift` and `zev threshold` catch metric regressions against a baseline automatically; `zev reproduce` re-runs a captured command and checks its output against the recorded result within a tolerance. **Provenance and memoization for CI.** CI can skip re-running a pipeline step entirely when the exact combination of source content, container image, and command has already succeeded once (see [Memoized CI](/docs/en/memoized-ci)). **Notarization and federated merge.** `zev notarize` anchors a snapshot's hash on-chain. `zev fedmerge` merges work from a `.car` file exchanged directly between two repositories, with no central server required. ## Who this is for zev was built as a real, working system — every feature described in this documentation was implemented, deployed to a real server, and verified against real commands and real data before being written up here. It is not a specification of intended behavior; it is a description of what the running system actually does.