build(railway): split Dockerfiles — web at root, MCP at Dockerfile.mcp#39
Merged
build(railway): split Dockerfiles — web at root, MCP at Dockerfile.mcp#39
Conversation
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>
Merged
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
After #37 merged, Railway's web deploy started failing. Root cause: Railway auto-detects a canonical-name `Dockerfile` at repo root and uses it for the build, overriding `"builder": "NIXPACKS"` in railway.json. Per Railway's own docs, there is no override that forces Nixpacks when a root Dockerfile is present. Our MCP Dockerfile runs `sema mcp` on stdio, which is wrong for the web deploy.
Previous successful deploy (0.2.3 via Nixpacks) is still serving traffic at semahash.org — Railway kept the last good deploy running — so nothing is down. This PR is the forward fix.
Fix: two Dockerfiles, each for its own consumer
Test plan
If deploy fails
Fallback: close this PR, revert to Nixpacks by putting the old `railway.json` back. Current site stays up either way because Railway doesn't roll back the running deploy on a failed redeploy.