Skip to content

docker-compose.yml: pin ghcr.io/ggml-org/llama.cpp:server-cuda to a specific digest (currently floating tag) #955

@joelteply

Description

@joelteply

Problem

`docker-compose.yml:297` uses `ghcr.io/ggml-org/llama.cpp:server-cuda` as a floating tag — no version, no digest pin. Image was rebuilt today against the latest `server-cuda` build. If upstream rolls or yanks the tag (rebuilds with breaking change, removes the tag, etc.), every Carl install silently breaks with no indication of the cause.

Carl impact

A Carl install today works → tomorrow upstream rebuilds → next Carl pull pulls a different image with potentially incompatible behavior (different llama.cpp build, different default flags, etc.). User sees inference fail with cryptic errors. Repro from us is impossible because we get a different image too.

This is the supply-chain version of the silent-failure-mode rule.

Fix direction

Pin to either:

  1. Specific tag: `ghcr.io/ggml-org/llama.cpp:server-cuda-b` where `` is the upstream build number — readable, but only if upstream tags this way (verify)
  2. Digest pin: `ghcr.io/ggml-org/llama.cpp:server-cuda@sha256:` — bulletproof immutable, opaque

Recommend digest pin — supply chain hygiene baseline. We can update the digest deliberately when we verify a new upstream version works.

Add a comment on the line explaining why it's pinned, with link to upstream changelog: `# Pinned to upstream build. Bump only after verifying behavior parity.`

Caught how

bigmama-wsl during 2026-04-23 PR validation, while reviewing all images Carl pulls.

Owner

Open — small, focused diff. Good first issue for someone learning compose pin patterns.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdependenciesPull requests that update a dependency file

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions