← zed-pkg home Private deployment

Run the registry where your packages live.

The hosted service is one deployment of an open Rust system. Organizations can point the CLI at their own registry, keep package metadata in Postgres, store immutable archives in S3-compatible object storage, and choose whether any public edge fallback is appropriate.

Deployment repositoryAPI server

Minimum service set

Rust write API

zed-api-server.rs owns authenticated publication and other state changes. Keep it behind your identity, authorization, and network controls.

Postgres

Stores package coordinates, versions, ownership, policy, and publication metadata. Backups and migration gates belong in the same operational plan as the application.

S3-compatible storage

Stores immutable tar.gz or zip artifacts by content identity. Cloudflare R2 is supported by the hosted topology, but the storage boundary is designed around S3-compatible APIs.

Optional web UI

zed-web-server.rs provides the Rust MASH web surface for browsing and account-aware product workflows. A CLI-only private registry can operate without exposing a public marketing application.

Optional edge layer

Cloudflare workers can separate public metadata and artifact reads from the origin, but private deployments should enable only routes that match their disclosure and trust policy.

Point clients at your boundary

The registry base is an explicit global CLI setting. Keep production, staging, and isolated test homes separate so cached state cannot make a readiness test appear healthier than a clean client. 

export ZED_PKG_REGISTRY="https://registry.packages.example"
export ZED_PKG_HOME="$HOME/.zed-pkg-example"

zed validate
zed install
zed install --frozen
Hermetic local mode

For package development and isolated CI, Zed also supports a file:// registry. Loopback and file registries stay hermetic by default instead of unexpectedly reaching public mirrors.

Deployment decisions to make explicitly

DecisionQuestionsConservative starting point
Network exposure Which metadata and artifact routes are public, private, or VPN-only? Keep writes private; expose reads only when package visibility is independently enforced.
Identity and authorization Who may claim namespaces, publish, yank, or manage organizations? Centralize authentication at the write/API boundary and audit every mutation.
Artifact retention How long are immutable versions retained, replicated, and backed up? Never overwrite a version; replicate content-addressed objects before promising availability.
Mirror trust May public or internal mirrors answer metadata, bytes, or neither? Permit pinned byte fallback first; require signed metadata and explicit client trust for range resolution.
Failure routing What happens when Postgres, object storage, or an edge worker is unavailable? Fail writes closed, preserve typed health signals, and test clean-client frozen restore regularly.

Readiness checklist

Before first package

  • Apply schema migrations and verify rollback/restore procedures.
  • Create an artifact bucket with encryption, retention, and least-privilege credentials.
  • Configure TLS, canonical hostnames, request limits, and health endpoints.
  • Define namespace ownership and publisher authorization.
  • Keep secrets outside repository files and workflow output.

Before production claim

  • Publish a disposable package through the actual CLI.
  • Install it from a clean home and verify the recorded digest.
  • Wipe the store and require a frozen reinstall with no lock drift.
  • Exercise origin-down behavior for both reads and writes.
  • Retain exact server, schema, CLI, and harness commit identities with the result.