Skip to content

docs(readme): lead the Docker section with the published image - #2196

Merged
igorls merged 2 commits into
developfrom
docs/docker-pull-and-mounts
Aug 8, 2026
Merged

docs(readme): lead the Docker section with the published image#2196
igorls merged 2 commits into
developfrom
docs/docker-pull-and-mounts

Conversation

@igorls

@igorls igorls commented Aug 8, 2026

Copy link
Copy Markdown
Member

Last piece of the #2177 follow-up, after #2187, #2188, #2189 and making the GHCR package public.

Why

The section only documented docker build, so every reader compiled locally even though the image is published multi-arch. And a clone builds develop — the default branch — not the release, so a build and a pull can hand you different versions with nothing saying so.

Beyond that it omitted the things that actually cost people time. All of these are verified below, not guessed.

What changed

  • Leads with docker pull ghcr.io/mempalace/mempalace:latest; building moved to the end, where it belongs (still required for the GPU variant, which is not published).
  • The MCP client config now mounts a transcripts directory. The old snippet mounted only the data volume, so the server started fine, the agent called mempalace_mine, and there was nothing there. Notes that paths are container paths from then on, and that ~ / $HOME are not expanded by every MCP client.
  • First-run model download (~80 MB minilm, ~300 MB embeddinggemma) into /data — it reads as a hung container otherwise.
  • Linux bind-mount permissions. The image runs as uid 1000 and bind mounts keep host ownership, so a 0700 directory fails with a bare PermissionError: [Errno 13]. Docker Desktop maps uids on macOS/Windows, which is why this is invisible to most of us — our own CI hit it in ci(docker): run the image before publishing it #2189. --user is explicitly called out as the wrong fix.
  • Examples mount the source :ro, since mining never writes to it.
  • The GPU image is x86_64-only.

Verification

Every command in the new section was run as written, against the published image on a fresh volume: pullmine /work:ro files a drawer → search returns it verbatim from a separate container → the MCP args array, verbatim, completes an initialize handshake. The untagged ghcr.io/mempalace/mempalace form used in the examples resolves correctly.

Claims checked rather than assumed:

claim how
/data is uid 1000, mode 700 stat inside the image
--user is the wrong fix --user 1234:1234 fails on a fresh volume, not just an existing one
read-only source mount suffices mined + read back verbatim through :ro
transcripts mount enables convo mining synthetic transcript mounted :ro, mine --mode convos filed and returned it
a clone builds develop, not the release local build reports 3.7.0; published image reports 3.6.0
GPU image is x86_64-only Dockerfile.gpu build reproduced failing on aarch64: onnxruntime-gpu (v1.25.0) only has wheels for manylinux_2_27_x86_64, manylinux_2_28_x86_64, win_amd64

tests/test_readme_claims.py: 42 passed.

Not included

website/guide/ still has no docker.md — the docs site covers Antigravity, Cursor, OpenClaw and others, but not Docker, so this README section remains the only Docker documentation. Separate PR if you want it.

The section only ever documented `docker build`, so every reader
compiled the image locally even though `ghcr.io/mempalace/mempalace` is
published multi-arch. Worse, a clone builds `develop` (the default
branch), not the release — a build and a pull could hand you different
versions with no hint that they differ.

Lead with `docker pull`, and cover the things that actually cost people
an evening:

- the container only sees what you mount, so the MCP client config now
  mounts a transcripts directory; without it the server starts fine and
  every mine finds nothing
- paths become container paths after that, and `~` / `$HOME` are not
  expanded by every MCP client
- the first embedding call downloads ~80 MB (minilm) or ~300 MB
  (embeddinggemma) into /data, which reads as a hung container
- bind mounts keep host ownership and the image runs as uid 1000, so a
  0700 directory fails with a bare PermissionError on Linux; Docker
  Desktop's uid mapping hides this on macOS and Windows. `--user` is
  called out as the wrong fix — /data is mode 700 owned by uid 1000, so
  another uid cannot write the palace at all
- mining never writes to its source, so the examples mount it read-only
- the GPU image is x86_64-only; onnxruntime-gpu has no aarch64 Linux
  wheels, so that build fails on Apple Silicon

Every command in the section was run as written against the published
image, and each claim checked rather than assumed: the uid and mode of
/data read out of the image, `--user` confirmed to break a *fresh*
volume, the read-only mount confirmed to still mine, and the aarch64 GPU
failure reproduced.
@igorls
igorls requested a review from milla-jovovich as a code owner August 8, 2026 22:46
Copilot AI lite review requested due to automatic review settings August 8, 2026 22:46

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@igorls
igorls merged commit 8516db7 into develop Aug 8, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants