Dockerfile + docker-compose.yml: rewrite for Rust stack lift

[moonexpr]

The current Dockerfile and docker-compose.yml build the legacy Python/FastAPI backend. The Phase-A backend rewrite (Python → Rust/axum) and the subsequent stack lift (app/ tree: Tauri + Rust sidecar + Vite/React 19 + Tailwind 4 + CodeMirror 6 + AI SDK v6 — branch lift/tauri-portable-pty-cm6-aisdk) leave the container path completely out of date.

This is a follow-up to the lift PR — the lift itself does not change Docker artifacts (the legacy backend/ + frontend/ trees still build from main until the cleanup PR).

Current state (broken / obsolete)

Dockerfile

# Final Stage for Backend and Frontend Assets
FROM python:3.11-slim
WORKDIR /app
...
COPY backend/requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY backend/ ./backend/
COPY --from=frontend-builder /app/frontend/dist ./frontend/dist
ENV PYTHONPATH=/app/backend
ENV PORT=8000
EXPOSE 8000
CMD [\"python\", \"-m\", \"uvicorn\", \"app.main:app\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\"]

• Python runtime + uvicorn entry — no longer applicable (current backend/ is Rust).
• backend/requirements.txt is gone.
• No app/ stage at all (lift binaries server-core + server-bin are unbuildable here).

docker-compose.yml

environment:
  - DATABASE_URL=sqlite+aiosqlite:///./data/claude_registry.db

• sqlite+aiosqlite:// is the Python async dialect; sqlx accepts sqlite:// (or no prefix and a plain path).

Expected rewrite

Multi-stage build, two paths to choose:

Option A — ship the current legacy Rust backend (faster, no lift dependency)

1. FROM rust:1.85-slim AS backend-builder — build the current Rust backend/ crate with cargo build --release.
2. FROM node:20-slim AS frontend-builder — build frontend/ (existing).
3. FROM debian:bookworm-slim final stage — copy the binary + frontend/dist, set FRONTEND_DIST=/app/frontend/dist, EXPOSE 8000, CMD [\"./backend-bin\", \"--host\", \"0.0.0.0\", \"--port\", \"8000\"].

Pros: minimal scope, ships what's on main today.

Option B — ship the app/ lift stack (post-cutover)

1. FROM rust:1.85-slim AS server-builder — cd app/server && cargo build --release -p server-bin.
2. FROM node:20-slim AS web-builder — cd app/web && npm ci && npm run build.
3. FROM debian:bookworm-slim final stage — copy server-bin + app/web/dist, set FRONTEND_DIST=/app/web/dist, EXPOSE 8000, CMD [\"./server-bin\"].
4. Optional: do not ship the Tauri desktop in the container — desktop is local-install only.

Pros: aligns the container with the lift target.

The cleanup PR (which renames backend/+frontend/ → legacy/) is the natural moment to commit to Option B.

docker-compose.yml updates

• DATABASE_URL=sqlite:///app/data/claude_registry.db (or omit — server-bin defaults to a local DB).
• Mount app/server/claude_registry.db location into the data volume.
• Optionally pass ANTHROPIC_API_KEY env so the in-container build supports the chat panel.

Repo locations

• Dockerfile (repo root)
• docker-compose.yml (repo root)
• app/server/ (lift Rust workspace) · app/server/bin/src/main.rs (server-bin entry)
• app/web/ (lift Vite/React) · app/web/dist/ (build output)
• backend/ (legacy Rust binary still on main)
• frontend/ (legacy Vite/React still on main)

Acceptance criteria

• docker compose up builds and starts the container without error.
• The UI is reachable at http://localhost:8000 and renders correctly.
• /api/v1/status returns 200 with version info.
• CC Bridge can spawn a child PTY inside the container (or the limitation is documented if Option B and portable-pty inside Docker is awkward).
• ANTHROPIC_API_KEY env is honored — chat panel works when the var is set.
• Image size is reasonable for a Rust binary + static dist (≲ 200 MB).

Where to look first

• Cargo workspace root: app/server/Cargo.toml
• Server-bin entry: app/server/bin/src/main.rs (reads HOST, PORT, DATABASE_URL, PRESENCE_PUBLIC_URL, ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL, FRONTEND_DIST).
• Web build: app/web/package.json (npm run build → app/web/dist/).

Context

Discovered during the Phase-D build/cutover pass of the stack lift, session 2026-05-23 (branch lift/tauri-portable-pty-cm6-aisdk). Out of scope for the lift PR per the canonical plan ("Dockerfile fix-or-file: Only blocking if container deploy is in scope at PR time"). Filed so the rewrite is not lost.

[moonexpr]

Dockerfile + docker-compose.yml were deleted in the lift PR (#3) since they were Python-era artifacts and the lift removes the legacy backend/+frontend/ paths they built from.

This issue stays open as the tracked want for a future container deploy. Recommended path (per the original issue) is Option B — multi-stage build pointing at app/server/bin + app/web/dist. Pick it up whenever container deploy is in scope.

[moonexpr]

Sprint triage — premise refresh + direction

Picking this up during a sprint on open issues/PRs. Two corrections to the issue as filed, then a recommended path:

1. The Dockerfile / docker-compose.yml no longer exist. Current repo has only .dockerignore — the quoted Python Dockerfile/docker-compose.yml have been removed since this was filed. So this is a write-from-scratch, not a rewrite-in-place.

2. Option A is stale. It assumes a Rust backend/ crate to cargo build --release. There is no backend/ — the legacy Python backend was renamed backend_python/ (still Python), and the Rust server lives at app/server (server-core + server-bin). So Option A as written isn't buildable.

→ Recommended: Option B (containerize the app/ stack). Multi-stage:

• FROM rust:1.85-slim AS server → cargo build --release -p server-bin (workspace at app/server)
• FROM node:20-slim AS web → build app/web → dist
• FROM debian:bookworm-slim → copy server-bin + web/dist, set FRONTEND_DIST, DATABASE_URL=sqlite:///app/data/claude_registry.db, run server-bin.
• Bonus: PR feat(server): unix-socket binding via SOCKET_PATH + dev.sh socket mode #10 (just opened) adds SOCKET_PATH unix-socket binding (perms 0660) to server-bin, so the nginx-upstream variant of compose is now straightforward — server-bin on a socket, nginx terminating in front.

Blocker for the implementation step: no Docker daemon is available in the current sprint environment, so I can't docker build to validate the image. Rather than commit an unvalidated Dockerfile, I'm leaving authoring to a Docker-capable environment (or say the word and I'll draft Option B unvalidated for you to build-test).