Shrink container image: multi-stage build, drop uv from runtime #44

New issue

Closed

opened 2026-06-12 02:07:27 +00:00 by coding-agent-marvin8 · 1 comment

coding-agent-marvin8 commented

2026-06-12 02:07:27 +00:00

(Migrated from codeberg.org)

The published container image carries unnecessary weight:

The uv binary is present at runtime but only needed at build time
The /dist wheel files remain in the image after installation
entry-point.sh calls uv run fedinesia which forces uv into the runtime

Switching to a multi-stage build with python:3.13-slim-bookworm as the final stage removes both uv and the wheel files from the published image. Pre-compiling bytecode (UV_COMPILE_BYTECODE=1) is a free bonus for faster cold starts.

The published container image carries unnecessary weight: - The `uv` binary is present at runtime but only needed at build time - The `/dist` wheel files remain in the image after installation - `entry-point.sh` calls `uv run fedinesia` which forces `uv` into the runtime Switching to a multi-stage build with `python:3.13-slim-bookworm` as the final stage removes both `uv` and the wheel files from the published image. Pre-compiling bytecode (`UV_COMPILE_BYTECODE=1`) is a free bonus for faster cold starts.

coding-agent-marvin8 commented

2026-06-12 02:07:41 +00:00

(Migrated from codeberg.org)

Findings

Builder stage: python:3.13-slim-bookworm + uv binary copied in via COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv. Setting UV_PYTHON_PREFERENCE=only-system ensures uv uses the image's own Python 3.13 rather than downloading a managed one.
Final stage: same python:3.13-slim-bookworm base — Python is at the same path in both stages so the venv symlinks are valid without any fixup.
entry-point.sh: swap uv run fedinesia for /run/.venv/bin/fedinesia. The installed console-script uses the venv's shebang directly, no activation needed.
UV_COMPILE_BYTECODE=1 pre-generates .pyc files in the builder so the final image has them ready.
Also removes the pointless chmod +x .venv/bin/activate (entry-point never sources it) and ls /dist debug line.

Plan of attack

Rewrite Containerfile as two-stage build, update entry-point.sh. One commit on branch fix/issue-41-42-container-fixes (will be included in PR #43 which already fixes #41 and #42).

**Findings** - Builder stage: `python:3.13-slim-bookworm` + uv binary copied in via `COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv`. Setting `UV_PYTHON_PREFERENCE=only-system` ensures uv uses the image's own Python 3.13 rather than downloading a managed one. - Final stage: same `python:3.13-slim-bookworm` base — Python is at the same path in both stages so the venv symlinks are valid without any fixup. - `entry-point.sh`: swap `uv run fedinesia` for `/run/.venv/bin/fedinesia`. The installed console-script uses the venv's shebang directly, no activation needed. - `UV_COMPILE_BYTECODE=1` pre-generates `.pyc` files in the builder so the final image has them ready. - Also removes the pointless `chmod +x .venv/bin/activate` (entry-point never sources it) and `ls /dist` debug line. **Plan of attack** Rewrite `Containerfile` as two-stage build, update `entry-point.sh`. One commit on branch `fix/issue-41-42-container-fixes` (will be included in PR #43 which already fixes #41 and #42).