A company can keep its packages in its own place and still use vibe unchanged. This page points a project or a whole machine at that place, with or without a search catalogue beside it, and keeps the public one as a fallback.
The agent runs `vibe registry add acme git@github.com:acme-specs --auth ssh --position primary`, which writes a new [registry](../glossary/index.xml#registry) block at the top of the [manifest](../glossary/index.xml#manifest)'s list. From now on every resolution asks `acme` first and the public registry second, and a package that exists in both comes from `acme`. `vibe registry test` probes each registry for reachability and authentication without fetching anything.
1. Add the registry to the project. The address is the organisation root, not a package repository:
2. Choose the authentication regime with `--auth`. The values are `none` for public read, `ssh` for keys and `credential-helper` for the system's git helper. `token-env` reads a token from an environment variable named after the host.
3. Probe with `vibe registry test`: it reports, per registry, whether the organisation answered and which authentication it accepted, without fetching anything.
Put the same registry block into `~/.vibe/registry.toml`. It is merged after each project's own list, so projects that name their registries are unaffected and projects that do not inherit the machine's. A project that names no registry, as `vibe init` creates them today, uses the machine's list, which is how a company's default becomes every new project's default.
A registry may point at a package that lives elsewhere. Instead of the package, the repository named after it carries one file, `vibe-redirect.toml`, with a `[redirect]` table: `target_url` names the repository where the package really is, and `ref_policy` says which tag to fetch there, the same tag by default or one `pinned_ref` for every version. A consumer installing the package sees no difference; the resolver follows the pointer once, never a chain, and records the stub's address in the [lock file](../glossary/index.xml#lock-file) as `via_redirect`.
The versions a consumer can see are the tags of the stub, not of the target: the registry's owner admits each version by tagging the stub. `vibe registry redirect` creates a stub, `redirect-sync` copies the target's tags into it after confirmation, and `redirect-update` changes the pointer. When a stub's target changes, because the maintainer moved to another host, a consumer accepts the switch with `--trust-redirect`; vibe never follows a changed target silently.
A token never lands in a file vibe writes and never appears in its output. With `--auth token-env` vibe reads it from `VIBEVM_REGISTRY_TOKEN_<HOST>` at run time and sends it over an encrypted connection only. Keep the variable in your shell profile or your CI secret [store](../glossary/index.xml#store), not in the repository.
A private registry without an [index](../glossary/index.xml#index-registry) still works; searches skip it and installs clone what they need. Add an index repository beside the packages and point `VIBEVM_INDEX_URL_ACME` at it to make searches and cold installs fast.
A [mirror](../glossary/index.xml#mirror) is not a second registry. Use `vibe registry set-mirror` for an alternative address of the same packages, verified against the same [fingerprints](../glossary/index.xml#fingerprint); use `registry add` for a different source of packages.
In a script that must notice a private registry being down, pass `--auth-required` to `vibe install`: an authentication error then stops the install instead of walking on to the public fallback.