# MCP Manager image build

The Dockerfile and full source for the **MCP Manager** image live in a separate Gitea repo:

- Source: <https://git.alexzaw.dev/alexz/mcp-manager>
- Published image: `git.alexzaw.dev/alexz/mcp-manager:<tag>`

This folder holds only a thin helper script (`build.sh`) that clones the source
repo and pushes the resulting image to the in-house Docker registry.

## Rebuild

```bash
cd build/
./build.sh                                 # builds + pushes :latest and the version tag
IMAGE_TAG=1.0.1 ./build.sh                 # override the tag
```

Requires `docker login git.alexzaw.dev` to already be done (or `~/.docker/config.json`
to have the registry credentials, which is the case on this host).

## Notes

- Two-stage build: `node:20-bookworm-slim` builds the React frontend, then a
  `python:3.11-slim` runtime stage serves the API + static UI on port `8001`.
- The runtime image bundles **Node 20** (copied from the bookworm node stage, so
  it's glibc-compatible — no NodeSource/apt) and **uv / uvx** (`pip install uv`),
  so the npx- and uvx-based MCP servers the app manages can actually run.
- All package caches/installs are pinned under `/data` via env vars
  (`NPM_CONFIG_CACHE`, `npm_config_prefix`, `UV_CACHE_DIR`, `UV_TOOL_DIR`, pip cache).
  Runtipi mounts `/data` to app-data, so MCP servers download once and persist.
- `amd64` only. Add `--platform linux/arm64` to `build.sh` args to cross-build
  (Node is copied from a multi-arch base, so this works).
- Upstream ships no `frontend/yarn.lock`; the Dockerfile resolves dependencies
  fresh at build time (no `--frozen-lockfile`).