Private reads and credentials
A private repository is a trusted source. The caller still needs permission to read it.
On this page
Private copies do not re-enter public admission#
Écluse reads private packages using the caller's credentials. Private metadata must meet the trusted integrity floor. Managed mirror versions must also meet their completion checks.
A conventional private npm artifact hit bypasses that metadata path and relies on the client's integrity verification.
Changing a public admission rule does not immediately block an existing private copy. See Admission, revocation, and retained copies.
The caller and worker have different authority#
The caller's credential authorises private reads and, by default, publication. The mirror worker has its own write credential.
A worker token does not give the caller private access. An explicit private authentication refusal stops the request rather than falling back to a public source.
When server.authToken is set, the shared edge token also travels to the private registry. That mode cannot preserve a different registry identity for each caller.
First-party names stay private#
A first-party declaration selects the private source exclusively. A missing first-party package stays missing. Écluse does not look for the same name publicly.
The declaration limits package names, not callers. Registry authentication still decides who may read or publish.
Digest conflicts raise an alarm#
When eligible public and private metadata disagree on digests, Écluse logs the conflict and increments its divergence counter.
An unmanaged private copy can remain listed and readable because the private repository is trusted. A disagreement proves neither copy correct.
Managed mirror checks still apply. Divergence alone never authorises cleanup.