Pakketcaches

fremforge draait geen aparte gedeelde caches meer voor gehoste runners. De cache is de eigen dependency-proxy van je organisatie, in dezelfde EU-regio als de runner-VM’s. Met runner pull-through aan, de standaard voor elke organisatie die geen eigen instellingen voor de dependency-proxy heeft opgeslagen, wordt elke job bij de start daarop gericht (zie Hosted runners):

Verkeer	Naar je proxy gericht via	Zonder runner pull-through, of bij terugval
npm, pnpm (via de npmrc van de job)	de registry-instelling van npm	`registry.npmjs.org`
pip en uv	`PIP_INDEX_URL`, `UV_DEFAULT_INDEX`	PyPI
Go, Maven, NuGet (elk als het in `runner_pull_through_ecosystems` staat, standaard alle drie)	`GOPROXY`, een Maven-mirror van Central, een `NuGet.Config` voor de hele machine	`proxy.golang.org`, Maven Central, nuget.org
Kwetsbaarheidsdatabase van Trivy (als `trivy` in de lijst staat)	`TRIVY_DB_REPOSITORY`, `TRIVY_JAVA_DB_REPOSITORY`	`ghcr.io/aquasecurity`
Container-images	de Docker-daemon van de job (zie Container-images)	de registry die de image noemt

Elke terugval gaat via de EU-egressproxy van fremforge naar de publieke registry. De proxy wordt aan het begin van elke job gecontroleerd; is hij niet bereikbaar, dan gebruikt de job de publieke registries en wordt de terugval gelogd.

De proxy draait in dezelfde OTC-regio als de runner-VM’s (eu-de, Duitsland). Een miss wordt via de egress van fremforge bij de upstream opgehaald en gecachet voor de volgende workflow van je organisatie.

Waarom dit automatisch gaat

Een gewone installatie van dependencies haalt bij elke build tientallen megabytes aan pakketten op. Zonder cache gaat dat verkeer elke keer door de NAT-gateway en wordt het van de publieke index gehaald. Met een cache komen warme pakketten uit opslag binnen dezelfde regio.

Je hoeft niets in te stellen: elke tool volgt zijn instelling automatisch. yarn en bun worden niet naar de proxy gericht; die installeren vanaf registry.npmjs.org via de egressproxy van fremforge.

Per workflow overschrijven

Om te overschrijven (bijv. als je uit een privéregistry moet ophalen), zet je de variabele in de env van je workflow:

jobs:
  build:
    runs-on: fremforge
    env:
      NPM_CONFIG_REGISTRY: https://npm.your-company.example/
    steps:
      - run: npm ci

Ook env: op stapniveau wordt gerespecteerd. De instelling van de klant gaat altijd vóór de standaard van fremforge.

pnpm 11 leest NPM_CONFIG_REGISTRY niet: zet ook PNPM_CONFIG_REGISTRY op dezelfde URL, anders blijft pnpm 11 vanaf registry.npmjs.org installeren.

Container-images

Met runner pull-through aan haalt de Docker-daemon van de job container-images op via de dependency-proxy van je organisatie, en worden ze voor je organisatie gecachet: docker pull, docker run, de FROM van een Dockerfile, en de job- en services:-containers. Namen van images blijven zoals ze zijn. Dit dekt ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws en registry.access.redhat.com voor elke organisatie. Is de proxy niet bereikbaar, of kan hij een pull niet afhandelen, dan wordt de image rechtstreeks uit de registry gehaald. Voor images is de proxy een cache, geen poort. Een docker buildx-builder met de driver docker-container haalt rechtstreeks op. Zie Hosted runners voor de details.

Images van Docker Hub

Er is geen gedeelde mirror van Docker Hub, en DOCKER_MIRROR_URL wordt niet meer gezet. Docker Hub (docker.io) gaat, net als registry.redhat.io en registry.connect.redhat.com, alleen via je proxy met de eigen inloggegevens van je organisatie. Zonder die gegevens is een docker pull of FROM van een Docker Hub-image in een workflow een anonieme pull rechtstreeks van Docker Hub, onderworpen aan de snelheidslimiet van Docker Hub voor anonieme pulls.

Zodra een eigenaar het Docker Hub-token van je organisatie in de dependency-proxy opslaat, gaan pulls van Docker Hub in je jobs via de proxy en worden ze gecachet, behalve in jobs van pull requests uit forks. Je kunt ook expliciet via frem.sh/<org>/dependency-proxy/docker.io/ ophalen. Zie Docker Hub-images ophalen via de dependency-proxy met je eigen Docker Hub-token.

`npm audit` en `pnpm audit` via de dependency-proxy

npm audit en pnpm audit sturen hun auditverzoek naar de registry waaruit ze installeren. Is die registry de dependency-proxy van je organisatie (https://frem.sh/_app/proxy/<org>/npm/), zoals bij jobs met runner pull-through aan, dan beantwoordt de proxy het verzoek zelf, in het bulk-advisoryformaat van npm, uit de eigen advisory-index van fremforge die is opgebouwd uit gegevens van OSV. De body van het verzoek is je exacte lijst met dependencies, en de proxy stuurt die niet door: hij bereikt nooit registry.npmjs.org of een andere externe advisorydienst. Het verzoek wordt geauthenticeerd zoals elk ander proxyverzoek, met een frem.sh-token dat pakketten in de organisatie mag lezen.

Ondersteunde clients: npm 7 en later, en pnpm 11 en later. Beide sturen POST /-/npm/v1/security/advisories/bulk, het enige audit-endpoint dat de proxy bedient. De body mag met gzip zijn gecomprimeerd, tot 4 MiB.
Niet ondersteund: npm 6 en pnpm 10 en eerder gebruiken de oudere audit-endpoints (/-/npm/v1/security/audits en /-/npm/v1/security/audits/quick), waarop de proxy antwoordt met 404. Gebruik npm 7 of later of pnpm 11, of geef pnpm --ignore-registry-errors mee.
pnpm 11 leest NPM_CONFIG_REGISTRY niet. Het haalt zijn registry uit PNPM_CONFIG_REGISTRY, een .npmrc of pnpm-workspace.yaml. Runner pull-through zet de proxy in de npmrc van de job, die pnpm 11 wel leest. Richt je een job zelf op de proxy met NPM_CONFIG_REGISTRY, zet dan PNPM_CONFIG_REGISTRY op dezelfde URL, anders installeert pnpm 11 vanaf registry.npmjs.org en stuurt het zijn audit daarheen.
Kan de advisory-index niet worden gelezen, dan antwoordt de proxy met 503 en Retry-After: 10 in plaats van een leeg rapport, zodat een mislukte opzoeking de audit laat falen in plaats van te lezen als “geen kwetsbaarheden”.
In het rapport wijzen advisory-URL’s naar osv.dev, en eindigt elke titel met de OSV-ID (bijvoorbeeld een GHSA-ID). Een versie waarvan bekend is dat ze kwaadaardig is, wordt gemeld als Malicious package (MAL-…). De numerieke advisory-id die npm toont, is afgeleid van de OSV-ID.

Wat NIET wordt gecachet

Privépakketten. De proxy haalt npm, PyPI, Go, Maven, NuGet en de andere pakketregistries anoniem op, dus hij bedient alleen publieke pakketten, en de eigen Authorization-header van je job wordt nooit naar upstream gestuurd. Privé-images op ghcr.io en quay.io, en Docker Hub en de Red Hat-registries, gebruiken de eigen upstream-inloggegevens van je organisatie. Overschrijf voor een privépakketregistry de betreffende variabele (NPM_CONFIG_REGISTRY, PIP_INDEX_URL, GOPROXY, …).
Dynamische API-aanroepen. API-aanroepen in GitHub-stijl (bijv. npm view <package> tegen api.npmjs.org) worden niet gecachet, alleen de registry-endpoints voor pakketgegevens.
Bronrepository’s. git clone-verkeer naar GitHub / GitLab / je eigen forge wordt niet gecachet. Gebruik het pakketregister van fremforge (https://frem.sh/api/packages/<org>/<type>/) als jij de bron beheert.
Container-images uit andere registries. Images uit registries die de dependency-proxy niet kent (gcr.io, een privéregistry) worden rechtstreeks opgehaald. Docker Hub en de Red Hat-registries worden alleen gecachet met de eigen inloggegevens van je organisatie; zie Images van Docker Hub. Stel een privéregistry per workflow rechtstreeks in.

Te verwachten prestaties

Koude cache (eerste pull van een nieuwe pakketversie): ~2-5 s trager dan upstream; de cache haalt bij upstream op, slaat op in OBS en geeft dan terug. Netto latentie = upstream-pull + schrijven naar OBS.
Warme cache (volgende pulls van dezelfde versie): ~30-60 s sneller dan upstream voor een gewone npm ci-run; de cache serveert vanuit OBS binnen dezelfde regio.
Horizon van de cache: je bewaarinstelling, standaard 90 dagen. Een gecachet bestand dat zo lang niet is opgehaald, wordt verwijderd; pakketversies en basisimages die je organisatie nog gebruikt, blijven bewaard. Zie Retention.

Het soevereiniteitsverhaal

De dependency-proxy draait in het eu-de-cluster van fremforge, en de opslag ervan is een OBS-bucket in eu-de. Het is eigen software van fremforge, gebouwd en uitgerold zoals de rest van het platform. Pulls bij upstream zijn anoniem, tenzij je organisatie eigen inloggegevens voor die upstream heeft opgeslagen (bijvoorbeeld Docker Hub); zie Upstream credentials.

Wat de upstream-registries ontvangen, staat beschreven onder What the upstream sees. Elke pull wordt vastgelegd in het toegangslog van het register van je organisatie (voor cachehits in CI: de pull census). De DPA dekt beide: het toegangslog in bijlage A.6, en de upstream-registries, die op jouw instructie worden gekozen en geen subverwerkers zijn, in bijlage B §B.9.

Status en incidentrespons

De dependency-proxy wordt bewaakt. Elke job controleert hem bij de start: is hij niet bereikbaar, dan installeert en haalt die job in plaats daarvan op uit de publieke registries via de egress van fremforge, en wordt de terugval gelogd. Verwachte impact: ~30-60 s extra per niet-gecachete pull. Om een proxy die halverwege een job faalt, wordt niet heen gerouteerd: npm en pnpm proberen het opnieuw, en een drukke proxy antwoordt met 503 en Retry-After (zie Errors).

Gerelateerd

Runner-image: wat er in de gehoste runner-image is ingebakken (kaniko, buildkit, taaltoolchains)
Secrets: hoe je per workflow inloggegevens voor een privéregistry injecteert
Uitgaande egress, toegestane bestemmingen en het gedrag van de uitgaande proxy worden behandeld in CI-runners