What is zev
What zev and Zaryn are, what they are made of, and what they can do.
Search for a command to run…
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.
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 (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:
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)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), 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).
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).
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.
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.