Skip to content

build: add Dockerfile for Glama check + containerized use#37

Merged
hwesterb merged 1 commit intomainfrom
ops/dockerfile-for-glama
Apr 18, 2026
Merged

build: add Dockerfile for Glama check + containerized use#37
hwesterb merged 1 commit intomainfrom
ops/dockerfile-for-glama

Conversation

@hwesterb
Copy link
Copy Markdown
Member

Needed for Glama's registry gating (see awesome-mcp-servers#5073 comment).

Their check bot spins up a container, starts the MCP server, and verifies it responds to introspection. Without passing that check, the awesome-mcp-servers PR won't merge — which blocks downstream cascades to mcpservers.org / PulseMCP / MCP.so / Automation Switch.

What's in the Dockerfile

Minimal. `python:3.12-slim` + `pip install "semahash[mcp]"` + `CMD ["sema", "mcp"]`. Stdio-only, no ports exposed.

Follow-up workflow

  1. Merge this PR.
  2. Submit sema at https://glama.ai/mcp/servers — upload this Dockerfile directly (they have a form field for it).
  3. Wait for Glama checks to pass (spins up container, does MCP introspection).
  4. Update awesome-mcp-servers PR #5073 with the Glama badge:
    `emergent-wisdom/sema MCP server`
  5. awesome-mcp-servers merges → cascades to every aggregator that pulls from it.

Needed for Glama's registry gating check (see PR #5073 comment). Glama's
check bot spins up a container, starts the MCP server, and verifies it
responds to introspection. Once Glama passes, awesome-mcp-servers PR can
merge, which in turn cascades to mcpservers.org / PulseMCP / MCP.so.

The container is minimal: pip install semahash[mcp], CMD sema mcp. Stdio
only — no network ports. Users who want to run sema via Docker instead of
uvx can `docker run -i` to wire their stdio.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@hwesterb hwesterb merged commit c4a2fac into main Apr 18, 2026
5 checks passed
@hwesterb hwesterb deleted the ops/dockerfile-for-glama branch April 18, 2026 15:44
hwesterb added a commit that referenced this pull request Apr 18, 2026
Problem: Railway's web deploy failed after PR #37 merged because Railway
auto-detects a canonical-name `Dockerfile` at repo root and uses it for
the build, overriding the explicit `"builder": "NIXPACKS"` in railway.json
(confirmed via Railway's own docs — there is no override that forces
Nixpacks when a root Dockerfile is present). The MCP Dockerfile runs
`sema mcp` on stdio, which isn't the web deploy.

Fix: give each consumer its own Dockerfile.

- `Dockerfile` (root, canonical) — multi-stage build that compiles the
  React frontend (Node 20) and runs the FastAPI server on $PORT via
  `sema serve`. This is what Railway auto-detects and consumes. Mirrors
  what the previous Nixpacks buildCommand + startCommand did, but in a
  single coherent artifact and without the "rebuild at startup to avoid
  COPY overwrite" workaround (Docker layers make that unnecessary).
- `Dockerfile.mcp` (non-canonical name) — the original stdio MCP server
  container, unchanged. This is the artifact submitted to Glama's
  admin form; the non-canonical name keeps Railway from touching it.
- `.dockerignore` — trims the build context (git, venvs, experiments,
  pre-built artifacts).
- `railway.json` — drops the Nixpacks-specific `build` block (no longer
  used since Railway will pick up the Dockerfile). Keeps healthcheck +
  restart policy.
- `nixpacks.toml` — kept for now as a breadcrumb of the previous build
  recipe; can be removed later once the Docker path is proven.

Previous successful deploy (0.2.3 via Nixpacks) is still serving traffic
at semahash.org, so nothing is down. This PR is the forward fix so the
next merge to main redeploys cleanly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
hwesterb added a commit that referenced this pull request Apr 18, 2026
Correcting the direction of #39. The root `Dockerfile` is now back to
the MCP stdio server (its original canonical-path content, the artifact
Glama fetches). The multi-stage web build lives at `Dockerfile.web`, and
Railway is configured via the `RAILWAY_DOCKERFILE_PATH` environment
variable to build from it instead of auto-detecting the root Dockerfile.

Also folds in the missing-include fix from PR #40: `.claude-plugin/`
and `skills/` must be COPY'd before `pip install` because hatchling's
`force-include` demands they exist at build time.

Env var set on Railway separately via `railway variable set`.

Effective layout after this PR:

- `Dockerfile`       MCP stdio server (unchanged from #37)       → Glama
- `Dockerfile.web`   Multi-stage web build                        → Railway
- `.dockerignore`    Trims build context                          → both
- `railway.json`     Healthcheck + restart policy only            → Railway

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

1 participant