For individuals
Explore packages on your own, then set up a personal namespace when you want to publish.
Zed supplements ecosystem-native package managers; it does not replace them.
It coordinates packages backed by the version-control servers you
already use - git, hg, jj and friends, on any forge. Authors publish
lean, tag-verified package metadata through
api.zpkg.net; public version metadata is read from
registry.zpkg.net; and immutable
artifact bytes are downloaded from
cdn.zpkg.net. Your backing
repo remains the provenance source. Consumers get one shared
content-addressed store per machine and pnpm-style symlinks per project.
$ zed add acme/http-kit@^1 resolving acme/http-kit ... 1.4.2 fetched 412 KiB (pruned artifact, not a clone) symlinked zed_modules/acme/http-kit -> ~/.zed-pkg/store/v1/9f/9f3ac2... $ zed publish verified git tag v0.3.0 at HEAD packed 96 KiB (38 files - 27 excluded: tests, ci, readme) published acme/http-kit@0.3.0 metadata -> https://api.zpkg.net artifact -> https://cdn.zpkg.net
One-off exploration or a shared package workspace: choose your path and see what is ready in the hosted-account rollout.
Explore packages on your own, then set up a personal namespace when you want to publish.
Create or choose a workspace for company packages, with a separate identity and explicit membership for each person.
Package managers grew heavy: full clones, vendored test suites, bloated per-project dependency folders. zed-pkg ships what runs and links the rest.
Not just git: hg, jj, sapling, fossil, and pijul are first-class citizens. Back your package with GitHub, GitLab, Bitbucket, Codeberg, SourceHut, Forgejo, Gitea - or a server in your rack.
Publishing strips tests, CI config, .github/ folders,
and even READMEs by default (licenses always ship). Laptops and
servers stop cloning entire repositories to use one library.
You cannot publish without a matching VCS tag (default
v{version}) pointing at the released commit.
Tag and commit are pinned in .zpkg.lock, so every
artifact traces back to source.
Installs pull small pre-built archives from CDN-backed object storage (Cloudflare R2 / S3) instead of cloning - faster for you, and it takes load off GitHub, GitLab, and friends.
One content-addressed store per machine at
~/.zed-pkg. Projects get symlinks in
zed_modules/, not copies. A hundred projects, one
download.
The registry is two small Rust services plus Postgres and any
S3-compatible bucket. Run private registries behind your firewall
with docker compose up, or point
ZED_PKG_REGISTRY at a file:// mirror.
A package is <org>/<name>, declared in a
.zpkg.toml at the repo root. TOML only - never YAML,
never JSON.
Tag the backing repo, then publish. zed verifies a clean tree and that the tag sits on HEAD, packs the pruned tar.gz, and uploads.
git tag v1.2.0 zed test-local # r2g: consume it first zed publish
The API records metadata in Postgres and writes the artifact to verified S3-compatible storage, addressed by sha256. Your forge anchors the source; the registry serves metadata and the CDN serves immutable bytes.
sha256 9f3ac2... tag v1.2.0 commit 84c1f9e
Semver resolution, one download into the global store, symlink
into the project. --frozen replays the lockfile
exactly.
zed install zed_modules/acme/http-kit -> ~/.zed-pkg/store/v1/9f/...
Review the exact credential-free release model before any registry write. The same JSON can be retained by CI or rendered as one self-contained offline HTML report with source provenance, exact destination counts, filtering, and no network dependencies.
zed release plan --json is the machine boundary for
Zed artifacts, native registries, and target-scoped forge mirrors.
Browser review consumes that model instead of reimplementing
release routing in JavaScript.
Official registry clients cover Rust, browser WebAssembly, TypeScript, Python, Go, Dart, Gleam, Erlang/OTP, Java, and Swift.
$ zed release plan --json \ > build/release-plan.json review Zed + native + forge routes retain JSON and offline HTML evidence $ zed publish
Built for OCI images and multi-stage Docker builds, not retrofitted to them.
Symlinks into $HOME break when layers move between
stages, so builds use
zed install --frozen --install-mode copy: fully
self-contained layers, still deduplicated at build time through a
--mount=type=cache on ~/.zed-pkg. The
test suite asserts copy-mode installs contain zero symlinks - and
runs the whole flow inside a clean container.
# build stage COPY .zpkg.toml .zpkg.lock ./ RUN --mount=type=cache,target=/root/.zed-pkg \ zed install --frozen --install-mode copy # artifacts are pre-pruned: no tests, no CI, # no readmes riding along into your image
zpkg.net will serve individual files out of published artifacts, unpkg-style but language-agnostic - import a stylesheet or a wasm binary straight from a package without installing it. Opinionated package serving on top of R2, not a generic blob store.
GET https://cdn.zpkg.net/v1/files/acme/ui-kit/1.2.0/dist/style.css
200 content-type: text/css cache-control: public, immutable planned - everything is free during early access
registry.zpkg.net is the public metadata host and cdn.zpkg.net serves
immutable package bytes; the repo you declare in
.zpkg.toml remains the mirror, backup, and provenance anchor.
Everything lives at github.com/zed-pkg. MIT, Rust at the core.