Sådan hoster du Verdaccio selv i 2026: npm-godkendelse, storage og TLS

Det bliver interessant at hoste Verdaccio selv ved den første redeploy – ikke ved den første docker run. Hvis npm-klienter sender godkendelsesoplysninger til en anden host, eller package storage er skrivebeskyttet, kan Docker stadig rapportere en helt sund proces. Deploymentet nedenfor er bygget op omkring observerbar adfærd: Log ind med npm, publicér en scoped package, installér den fra et rent projekt, og bekræft, at en upstream-package bliver cached.

Verdaccios tilsigtede rolle er klar: et privat npm-register til interne packages. Den beskrivelse fortæller os, hvad der skal være offentligt, hvad der bør forblive privat, og hvad en backup skal kunne genskabe.

Porte, processer og private services

Et nyttigt Verdaccio-diagram viser den offentlige route, den private port 4873, state-grænsen og alle understøttende krav. Markér, hvilke pile der indeholder credentials, og hvilke der er almindelig brugertrafik. Netværkskontrakten for Verdaccio består af persistent konfiguration, htpasswd-storage og eventuel object storage. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Verdaccio en afgrænset service credential.

Bevis diagrammet med én reel handling: Log ind med npm, publicér en scoped package, installér den fra et rent projekt, og bekræft, at en upstream-package bliver cached. Den sandsynlige belastning kommer fra tarball-storage, metadataoperationer, samtidige installationer og latenstid til konfigurerede upstream-registre; overvåg denne sti i stedet for at behandle alle HTTP-requests ens.

Gør den lokale kommando til en inspicerbar service

Brug en kommando, der synliggør alle vigtige valg. Denne baseline binder Verdaccio til hostens loopback, tilføjer de kendte data mounts og angiver den første nødvendige indstilling. Tilføj de gennemgåede forbindelsesindstillinger for persistent konfiguration, htpasswd-storage og eventuel object storage; brug private navne til private services.

docker run -d \
  --name verdaccio \
  --restart unless-stopped \
  -p 127.0.0.1:4873:4873 \
  -v verdaccio-data:/verdaccio/storage \
  -e VERDACCIO_PUBLIC_URL=https://app.example.com \
  verdaccio/verdaccio:latest

Erstat floating tags med en testet version eller digest. Efter opstart skal du inspicere docker logs --tail 200 verdaccio og bekræfte, at processen lytter på 4873. Udfør derefter Verdaccio-accepttesten; et svar fra root-siden kan ikke bevise, at hele scenariet lykkes: Log ind med npm, publicér en scoped package, installér den fra et rent projekt, og bekræft, at en upstream-package bliver cached.

TLS er nemt; genererede URL'er er ikke

Sæt den offentlige URL og npm-registerets URL til den samme HTTPS-origin. Send det valgte hostname til containerens port 4873, videresend den oprindelige host og HTTPS-scheme, og undgå at publicere en ekstra direkte origin.

Test Verdaccio fra en ren ekstern client. Adskil ingress-fejl fra den kendte applikationsgrænse – npm-klienter sender godkendelsesoplysninger til en anden host, eller package storage er skrivebeskyttet. En certifikat-, DNS- eller 502-fejl hører til routing; en request, der når Verdaccio og fejler senere, hører til applikationens state, kapacitet eller en understøttende afhængighed. Guiden til TLS med custom domain dækker den første gruppe.

Gendan Verdaccio på en tom host

For Verdaccio starter sikker redeployment med package-tarballs, metadata, konfiguration og authentication-filer. Mount /verdaccio/storage før bootstrap, skriv harmløse eksempeldata, og erstat containeren for at bevise, at stien faktisk er persistent. Test stien ved at erstatte containeren, mens de harmløse eksempeldata findes; det afslører mounts, der peger en mappe for højt eller for lavt.

Test derefter disaster recovery på en tom host. Brug et applikationskonsistent databaseeksport, hvor det er nødvendigt, og verificér, at private tarballs, metadata, brugere og konfiguration vender tilbage, og at det rene projekt installerer med samme package integrity. Guiden til database-backups, du har gendannet angiver et stærkere mål end blot at kontrollere, at der blev oprettet en arkivfil.

Credentials, roller og eksponerede flader

For Verdaccio er den værdifulde overflade ikke nødvendigvis landingssiden. Den største fejl er at tillade anonym publish eller bruge en skrivbar uplink-konfiguration. Modvirk det bevidst: Afvis anonym publish, afgræns maintainers, og sørg for, at npm-godkendelse er knyttet til den præcise HTTPS-registerhost.

VERDACCIO_PUBLIC_URL er konfiguration og ikke en secret; hold værdien eksplicit, mens du beskytter de separate credentials, som Verdaccio bruger. Brug en unprivileged container-bruger, når imaget understøtter det, og mount ingen uvedkommende credentials. Anvend rate- eller størrelsesbegrænsninger ved ingress, hvor ikke-betroet arbejde kan bruge tarball-storage, metadataoperationer, samtidige installationer og latenstid til konfigurerede upstream-registre.

Fejlsimulering for Verdaccio

Kapacitetstests skal belaste tarball-storage, metadataoperationer, samtidige installationer og latenstid til konfigurerede upstream-registre – ikke sende gentagne requests til /. Kør scenariet “log ind med npm, publicér en scoped package, installér den fra et rent projekt, og bekræft, at en upstream-package bliver cached” med realistisk samtidighed, og registrér latenstid, fejlrate og vækst i storage.

Upgrade-planlægningen skal tage højde for denne risiko: Konfigurationssyntaks, authentication-plugins og package-metadata skal testes mod den målrettede Verdaccio-majorversion. Test den nye release med repræsentativt input, gentag derefter accepttransaktionen, og sammenlign resultatet. Hvis npm-klienter sender godkendelsesoplysninger til en anden host, eller package storage er skrivebeskyttet, skal du registrere den fejlslagne transaktion og inspicere den første involverede grænse i stedet for at antage, at ingress er ansvarlig.

Bevis Verdaccio-deploymentet fra ende til anden

Lad ikke trafik fra den første bruger være accepttesten for Verdaccio. Forbered harmløs eksempel-state, og kør den komplette handling “log ind med npm, publicér en scoped package, installér den fra et rent projekt, og bekræft, at en upstream-package bliver cached”. Notér den præcise offentlige URL, resultatet, image-referencen og det loginterval, der er knyttet til kørslen.

Erstat containeren, og gentag uden at genopbygge data. Gendan derefter på en tom host; gendannelsesbetingelsen er, at private tarballs, metadata, brugere og konfiguration vender tilbage, og at det rene projekt installerer med samme package integrity. Observer tarball-storage, metadataoperationer, samtidige installationer og latenstid til konfigurerede upstream-registre ved hver gennemgang, og definér en alarm omkring forringelse af transaktionen i stedet for omkring inaktive container-metrics.

Én sidste kontrol bør fejle med vilje: Afvis midlertidigt testidentitetens adgang til persistent konfiguration, htpasswd-storage og eventuel object storage. Bekræft, at den resulterende Verdaccio-meddelelse identificerer den relevante grænse i stedet for at udløse sletning af data eller en endeløs restart. Gendan den gyldige tilstand, og bekræft, at den samme eksempeltransaktion lykkes. Behold denne korte øvelse i release-checklisten.

Hold Verdaccio eksplicit, mens Dockup håndterer routing

For Verdaccio kan Dockup oprette routen og TLS-certifikatet, bevare mounts, levere secrets og placere persistent konfiguration, htpasswd-storage og eventuel object storage på private netværk, mens deploymentet sker på enten Dockup eller tilknyttede servere.

Release-gaten er stadig den konkrete Verdaccio-transaktion: Log ind med npm, publicér en scoped package, installér den fra et rent projekt, og bekræft, at en upstream-package bliver cached. Verificér også gendannelsesbetingelsen – private tarballs, metadata, brugere og konfiguration vender tilbage, og det rene projekt installerer med samme package integrity. De to kontroller viser, om deploymentet fungerer, og om det kan gendannes.

Ofte stillede spørgsmål

Hvad har Verdaccio brug for i et produktionsdeployment?

Route Verdaccio-containeren via port 4873 gennem én HTTPS-origin. Det understøttende netværkskrav er persistent konfiguration, htpasswd-storage og eventuel object storage. Kald ikke Verdaccio klar, før du kan logge ind med npm, publicere en scoped package, installere den fra et rent projekt og bekræfte, at en upstream-package bliver cached.

Hvilke Verdaccio-data hører hjemme i en backup?

Gør /verdaccio/storage persistent, og inkludér package-tarballs, metadata, konfiguration og authentication-filer i det samme recovery-manifest. En ren Verdaccio-gendannelse er kun godkendt, når private tarballs, metadata, brugere og konfiguration vender tilbage, og det rene projekt installerer med samme package integrity.

Kræver Verdaccio HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Verdaccio-origin, og behold port 4873 på den interne route. Anvend Verdaccio-indstillingen korrekt: Sæt den offentlige URL og npm-registerets URL til den samme HTTPS-origin. For Verdaccio beskytter HTTPS credentials eller brugerindhold under transport og holder origin-følsom klientadfærd konsistent.

Hvordan bør en Verdaccio-upgrade testes?

Gendan den aktuelle Verdaccio-state i et isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi konfigurationssyntaks, authentication-plugins og package-metadata skal testes mod den målrettede Verdaccio-majorversion. Behold det tidligere Verdaccio-image, indtil dets datamigrerings- og rollback-grænse er forstået.