---
status: located
opened: 2026-09-18
located-in:
  - mesh-catalog
  - mesh-controller
fixed-by:
amended-design:
---

# 064 — A mesh build cannot fetch a module's external dependencies

## Symptom

Three modules cannot be built by the mesh's own builder, each because the build needs an artifact
from a public registry the build environment does not reach:

- A module whose runtime installs an npm package its code imports (`npm install` in the
  Dockerfile) fails with a 404 — the build's npm is pointed at the mesh's own registry, which does
  not carry the public package.
- A module whose runtime copies a binary out of a public image (`COPY --from=vendor/tool:latest`)
  fails with `pull access denied` — the build's container runtime reaches the mesh's registry, not
  the public one.

apt-based installs in the same Dockerfiles succeed, so the build has ordinary internet: it is npm
and image pulls specifically that are redirected to the mesh's registry. Observed while giving the
catalogue its build sections (hq issue 060): 44 of 70 modules build from their own source with no
external fetch; these three need one and stop.

## Why it matters beyond the instance

The delivery design says a module is built by the mesh from a repository and a path (ADR 0069),
compiled against the sdk and tool runtime the base images already carry. That holds for a module
whose only dependencies are the base's — but a module with a third-party runtime dependency, or a
tool binary from a vendor image, has no sanctioned way to bring it into a mesh build. The
workstation build script got away with it by running on a host with public npm and Docker Hub;
retiring that shortcut (the no-fake principle) exposes that the mesh has no answer.

Left unanswered, "the mesh builds its own catalogue" is true only for modules that happen to have
no external dependency, and which those are is invisible until each is built.

## Open questions

- Should a module's third-party npm dependencies be published to the mesh's own registry as part
  of building it (a dependency is an artifact like any other), or should the build environment
  proxy the public registry read-only?
- Is a vendor binary (`mc`, and others like it) the same question as an npm dependency, or does it
  want a distinct answer — a module declaring an external image as a build input the mesh
  pre-fetches and pins, the way it pins its bases?
- Should a manifest that declares a build whose Dockerfile fetches from a public registry be
  refused at `module add`, so the gap is caught at registration rather than at build?