fix: enable git-over-ssh cloning for private repo installs

The manager image had git but not openssh-client, so ssh:// clones
failed outright ("cannot run ssh"). Install openssh-client, and mount
an SSH_DIR (key + known_hosts) into the container read-only so private
repos can actually authenticate — confirmed both gaps while deploying
against real private Zenvairo repos.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.env.example

@@ -28,3 +28,8 @@ MASTER_KEY=change-me-to-a-random-string-of-at-least-32-characters
 # Resource caps applied to every installed MCP container (same limit for all, no per-installation override in V1)
 CONTAINER_MEMORY_MB=512
 CONTAINER_CPUS=1
+
+# Absolute path to an SSH dir (key + known_hosts) with clone access to the repos you'll
+# install, mounted read-only into the manager container so `git clone ssh://...` works for
+# private repos. Required only if you install from private/SSH repo URLs.
+SSH_DIR=/root/.ssh

Dockerfile

@@ -23,7 +23,7 @@ RUN npm run build --workspace apps/web
 RUN npm run build --workspace apps/server
 
 FROM node:20-slim
-RUN apt-get update && apt-get install -y --no-install-recommends git ca-certificates \
+RUN apt-get update && apt-get install -y --no-install-recommends git openssh-client ca-certificates \
   && rm -rf /var/lib/apt/lists/*
 COPY --from=nixpacks /usr/bin/nixpacks /usr/local/bin/nixpacks
 COPY --from=dockercli /usr/local/bin/docker /usr/local/bin/docker

LESSONS.md

@@ -14,6 +14,14 @@ image stays the same — only pinning by digest guarantees bytes. For a single b
 prefer downloading the pinned release asset directly from the project's GitHub releases (a
 specific `vX.Y.Z` tag + exact filename) over extracting it from someone else's Docker image.
 
+## `git clone ssh://...` needs an actual `ssh` binary, and a key
+
+`node:20-slim` ships `git` but not `openssh-client` — cloning an `https://` repo works, but
+`ssh://` fails with "cannot run ssh: No such file or directory". Fixed by installing
+`openssh-client` in the final image. Separately, even with `ssh` present, cloning a private
+repo needs a key with access mounted into the container (`SSH_DIR` in `docker-compose.yml`,
+reusing the host's own deploy key) — confirmed both failures back to back while deploying.
+
 ## Nixpacks silently picks its own default runtime version
 
 Nixpacks does not fail when a repo's `engines`/version requirement isn't met — it silently falls back to its own default (e.g. picked Node 18 for a repo requiring Node >=20 in `Social-MCP`). The build goes green, then the container crashes at runtime (`crypto is not defined`, missing globals, etc.).

docker-compose.yml

@@ -18,6 +18,10 @@ services:
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock
       - ./data:/repo/data
+      # Reuses the host's own SSH key/known_hosts so the manager can `git clone` private
+      # repos over ssh:// the same way the host itself already does. Read-only.
+      # SSH_DIR must be an absolute path (compose doesn't expand "~").
+      - ${SSH_DIR}:/root/.ssh:ro
     networks:
       - mcp-net