[Bug] docker compose up pulls a 2024 published image that crashes on startup (corepack signature failure)

[colinwilliams91]

Describe the Bug
A fresh clone + docker compose up -d produces a stack where the api
service never starts, while worker, redis, and puppeteer-service come up
fine. docker compose build && docker compose up -d works.

The cause is not the source. docker compose up pulls the published
trieve/firecrawl:latest image, which was built 2024-09-06 and no longer
starts.

To Reproduce

System

• Docker Desktop on Windows (Windows Containers backend)

git clone https://github.com/devflowinc/firecrawl-simple.git
cd firecrawl-simple
docker compose up -d
docker compose ps          # api is absent
docker compose logs api

Logs

api-1 | Error: Cannot find matching keyid: {"signatures":[...],"keys":[...]}
api-1 | at verifySignature (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:21535:47)
api-1 | at fetchLatestStableVersion (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:21553:5)
api-1 | at async Engine.getDefaultVersion (...)
api-1 | at async Engine.executePackageManagerRequest (...)
api-1 | Node.js v20.17.0

---

Why

docker-compose.yaml gives the api service both an image: and (via the
x-common-service anchor) a build::

x-common-service: &common-service
  build: apps/api
services:
  api:
    image: trieve/firecrawl
    <<: *common-service
  worker:
    <<: *common-service        # no image: key

When a service declares both, Compose pulls the named image if it isn't already
local and only builds as a fallback. So api runs the registry artifact;
worker — which has no image: key — always builds from source. Hence one
starting and the other not, from the same Dockerfile.

The published image predates npm's registry signing-key rotation, so its
bundled corepack can't verify the pnpm download and exits before the app runs.

Evidence

Comparing the pulled image against a local build of the same Dockerfile:

	trieve/firecrawl:latest (pulled)	local docker compose build
Created	2024-09-06	2026-07-15
Node	v20.17.0	v20.20.2
corepack	0.29.3	0.35.0
packageManager in /app/package.json	pnpm@9.9.0	pnpm@9.12.3

docker pull trieve/firecrawl:latest
docker image inspect trieve/firecrawl:latest --format '{{.Created}}'
# 2024-09-06T14:14:32.200421433-07:00

docker run --rm --entrypoint sh trieve/firecrawl:latest -c 'node --version; corepack --version'
# v20.17.0
# 0.29.3

apps/api/Dockerfile already does RUN npm install -g pnpm corepack@latest, so
a current build picks up corepack with the rotated keys. The Dockerfile is
fine — the published image just predates it.

Workaround

docker compose build && docker compose up -d
# or
docker compose up -d --build

Possible fixes

Depends on your intent for the published image:

1. If trieve/firecrawl:latest is meant to be a supported artifact — it
   needs rebuilding and republishing, and probably a CI job so it doesn't drift
   again. Note apps/api/Dockerfile uses FROM node:20-slim unpinned, so the
   image's Node version is whatever the tag resolved to at build time (20.17.0
   here).
2. If building locally is the expected path — the image: key on api is a
   trap. Either drop it (matching worker, which has none) or set
   pull_policy: build.

Happy to open a PR for either approach but the CI one is a little less accessible to me.