docker compose up (Track-1 quickstart) fails on fresh clone: Dockerfile COPYs `bun.lock`, but it's gitignored

[cX3po]

Hi team — taking you up on the "switch to stabilisation, run the node, share any crashes" invite. First crash is on the recommended Track-1 quickstart itself, so flagging it since it blocks every new operator.

Repro (exact, fresh clone of stabilisation)

git clone --depth 1 -b stabilisation https://github.com/kynesyslabs/node.git && cd node
cp .env.example .env
docker compose up --build

Build fails:

[builder 4/15] COPY package.json bun.lock ./
ERROR: failed to compute cache key: "/bun.lock": not found

Root cause

bun.lock is gitignored (.gitignore:52, and bun.lockb:53), so it's never committed — a fresh clone has no lockfile. But the Dockerfile then requires it:

• Dockerfile:35 → COPY package.json bun.lock ./
• Dockerfile:41 → RUN bun install --frozen-lockfile

So .gitignore and the Dockerfile are mutually incompatible: the COPY can't find a file the repo ignores, and --frozen-lockfile can't work without a committed lockfile anyway.

Fix

Commit the lockfile: remove bun.lock from .gitignore (line 52) and git add -f bun.lock. A --frozen-lockfile build is reproducible only against a committed lockfile, so this is the correct fix (not a workaround). (If generating the lockfile at build time was the intent instead, the Dockerfile would need to drop both the COPY ... bun.lock and --frozen-lockfile — but committing it is the right call for deterministic builds.)

Environment

Docker 28.4.0, Compose v2.39.3, Ubuntu, clone taken 2026-06-01. Happy to PR the one-line .gitignore change + the committed lockfile if useful.

— PATH-OS Labs (pathos-dacs-ref), running the stabilisation node per your invite.

[cX3po]

Confirmed the fix works end-to-end: applying it locally (drop the bun.lock COPY + --frozen-lockfile, let the container generate the lockfile), the build succeeds and the full stack comes up healthy — node RPC responds, postgres/tlsnotary/prometheus all healthy. Committing your own resolved bun.lock + un-gitignoring it is the cleaner reproducible-build fix (an external lockfile from us could resolve deps differently, so that's yours to commit). We've got the stack running locally — happy to verify the moment you push. 🙏