Paquetes privados y mirror transparente de npmjs.org en un binario Rust. Funciona con npm 7–11, yarn classic, yarn berry 2/3/4, pnpm y bun — sin contenedor Verdaccio.
Publica paquetes privados scoped o unscoped y espeja registry.npmjs.org (o cualquier upstream compatible) desde el mismo endpoint /registry/npm/. Las publicaciones privadas siempre tienen prioridad sobre las entradas del proxy — no hace falta scope routing en .npmrc.
npm 7–11, yarn classic 1.22, yarn berry 2/3/4, pnpm 9/10 y bun. Toda la autenticación, los dist-tags, publish, install, deprecate y unpublish están probados end-to-end contra cada cliente.
Los packuments upstream se cachean y revalidan con If-None-Match (corto-circuito 304). Los tarballs se descargan perezosamente en el primer install y un GC LRU en segundo plano mantiene el caché en disco bajo un límite configurable.
Los tarballs se transmiten vía axum::Body::from_stream — Pier nunca bufferiza un tarball de 200 MiB en RAM. El camino hot usa tokio_util::ReaderStream para mantener la memoria acotada sin importar el tamaño del paquete.
npm login --auth-type=web abre el navegador, el usuario se autentica en el panel con 2FA y un token pier_npm_ de larga duración aterriza en .npmrc — sin copiar y pegar tokens a mano.
La pestaña Mirror lista cada paquete público en caché con su número de versiones y tamaño en disco. Marca los paquetes que le importan al equipo y filtra el resto. Cada fila enlaza a una página de detalle con dist-tags, versiones y un botón Descargar última.
Abre Packages → Manage tokens → New token. Pier devuelve un pier_npm_… que se muestra una sola vez — cópialo antes de cerrar el modal.
registry=https://your-pier-host/registry/npm/, luego //your-pier-host/registry/npm/:_authToken=pier_npm_…, más always-auth=true para que yarn 1 envíe el bearer en los GET.
Packages → Upstream proxy → activa el toggle, el upstream por defecto es registry.npmjs.org. Configura el tamaño máximo de caché (0 = ilimitado) y el TTL para revalidación de packuments.
npm publish para un paquete privado, o npm install <cualquier-paquete-público> para llenar el caché del proxy. Todo el equipo usa la misma URL — sin scope routing.
Para publicación privada + mirror proxy, sí — Pier implementa el mismo protocolo HTTP de registro npm, además de dist-tag/deprecate/unpublish desde CLI y flujo de login web. Aún no hay paridad en: npm search, npm owner/RBAC y endpoints de audit, que están en la hoja de ruta. Todo lo demás se valida contra una matriz automática de clientes (npm/yarn1/yarn2/yarn3/yarn4/pnpm/bun).
npm 7 a 11, yarn classic 1.22, yarn berry 2/3/4 (con npmAlwaysAuth: true en .yarnrc.yml), pnpm 9 y 10, y bun latest. Cada cliente se ejecuta contra una instancia real de Pier en CI dentro de pier-tests, así el comportamiento queda fijado entre upgrades.
Pier cachea la capa de metadatos (packuments) para siempre con revalidación basada en TTL, y la capa de tarballs de forma perezosa — solo las versiones que un cliente instaló de verdad acaban en disco. Una CDN cachea respuestas HTTP de forma opaca; Pier entiende el protocolo npm, por eso puede servir packuments abreviados, responder 304 ante If-None-Match y reescribir URLs de dist.tarball para que los installs siempre pasen por tu host.
Sí — yarn 2/3/4 usan .yarnrc.yml en vez de .npmrc y requieren npmAlwaysAuth: true para enviar el bearer en GET. Con esa línea de configuración, el flujo completo de install/publish funciona contra Pier; la página de docs de yarn berry incluye un .yarnrc.yml listo.
Sí — las entradas privadas y de proxy viven en el mismo endpoint /registry/npm/. Las publicaciones privadas siempre tapan a las entradas de proxy con el mismo nombre, así que puedes mantener un scope interno @tu-org/* e instalar left-pad o next por la misma URL.
Los packuments son pequeños (cada paquete ≈ 1–50 KB de JSON). Los tarballs son lo gordo: un solo npm install next se lleva ~100 MiB entre dependencias transitivas. Para una máquina de dev personal, 500 MiB es cómodo; para un equipo pequeño 2–5 GiB; para mirrors de CI 20+ GiB. Pon Max cache size a 0 para ilimitado.
Los tokens se generan en el panel donde la sesión del operador exige 2FA — así el flujo npm login --auth-type=web hereda 2FA de forma natural. El npm login clásico (CouchDB) no pide OTP hoy; recomendamos desactivarlo desde la configuración del panel si quieres 2FA obligatorio en cada generación de token.
Usa un token de larga duración (Packages → Manage tokens) y escribe el mismo .npmrc en tu paso de CI. Para GitHub Actions y GitLab CI hay snippets listos en la página de docs de CI, funcionan para cualquiera de los clientes soportados.
Un comando instala Pier en cualquier VPS Ubuntu o Debian.
curl -fsSL https://pier.sh/install | sudo bash