From 698173c79d6c7686ad63b7e3322ba747dc51ec7d Mon Sep 17 00:00:00 2001 From: Dasemu Date: Thu, 8 Oct 2026 04:31:55 +0200 Subject: [PATCH] fix: copy the docker buildx plugin so nixpacks builds actually work nixpacks shells out to `docker build`, which defaults to BuildKit; without the buildx CLI plugin every build failed outright. Co-Authored-By: Claude Sonnet 5 --- Dockerfile | 3 +++ LESSONS.md | 8 ++++++++ 2 files changed, 11 insertions(+) diff --git a/Dockerfile b/Dockerfile index 5a20bc6..389015f 100644 --- a/Dockerfile +++ b/Dockerfile @@ -27,6 +27,9 @@ RUN apt-get update && apt-get install -y --no-install-recommends git openssh-cli && rm -rf /var/lib/apt/lists/* COPY --from=nixpacks /usr/bin/nixpacks /usr/local/bin/nixpacks COPY --from=dockercli /usr/local/bin/docker /usr/local/bin/docker +# nixpacks shells out to `docker build`, which defaults to BuildKit — needs the buildx +# plugin present or it fails with "BuildKit is enabled but the buildx component is missing". +COPY --from=dockercli /usr/local/libexec/docker/cli-plugins/docker-buildx /usr/local/libexec/docker/cli-plugins/docker-buildx WORKDIR /repo COPY package.json package-lock.json ./ diff --git a/LESSONS.md b/LESSONS.md index c9f5bda..00540fb 100644 --- a/LESSONS.md +++ b/LESSONS.md @@ -22,6 +22,14 @@ specific `vX.Y.Z` tag + exact filename) over extracting it from someone else's D repo needs a key with access mounted into the container (`SSH_DIR` in `docker-compose.yml`, reusing the host's own deploy key) — confirmed both failures back to back while deploying. +## `docker build` needs the buildx plugin present to use BuildKit + +Nixpacks shells out to `docker build`, which defaults to BuildKit. The manager's image only +copied the bare `docker` CLI binary from `docker:27-cli`, not its buildx plugin, so every +build failed with "BuildKit is enabled but the buildx component is missing or broken" — +confirmed on the first real build attempt. Fixed by also copying +`/usr/local/libexec/docker/cli-plugins/docker-buildx` from the same `docker:27-cli` image. + ## Nixpacks silently picks its own default runtime version Nixpacks does not fail when a repo's `engines`/version requirement isn't met — it silently falls back to its own default (e.g. picked Node 18 for a repo requiring Node >=20 in `Social-MCP`). The build goes green, then the container crashes at runtime (`crypto is not defined`, missing globals, etc.).