From e20b893adccf51cf675a9e499d2f61eeb7ac3e6e Mon Sep 17 00:00:00 2001 From: AJ Date: Wed, 9 Sep 2026 21:52:26 +0800 Subject: [PATCH] fix: install litestream in Dockerfile to prevent Railway deploy failure PR #51 added a Dockerfile for Glama.ai MCP verification, but Railway used it to build production (despite railway.json pinning "builder": "NIXPACKS") and the deploy failed: Deploy > Create container The executable `/app/bin/litestream` could not be found. railway.json's deploy.startCommand always wraps uvicorn with litestream for continuous SQLite replication, regardless of which builder produced the image. Previously only nixpacks.toml's [phases.litestream] installed that binary. This Dockerfile now installs the identical binary (same version/URL as nixpacks.toml), so it is correct no matter which builder Railway picks. Production itself was not affected -- Railway kept serving the last successful deploy -- but every subsequent deploy would have failed the same way until this is merged. --- Dockerfile | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/Dockerfile b/Dockerfile index 4434d4e..cf522df 100644 --- a/Dockerfile +++ b/Dockerfile @@ -16,8 +16,11 @@ WORKDIR /app # C++ library with Python bindings) doesn't ship a prebuilt wheel for # whatever platform Glama builds on -- without it, that one line in # requirements.txt could fail to install and take the whole build down. +# +# curl is needed for the litestream install step below. RUN apt-get update && apt-get install -y --no-install-recommends \ build-essential \ + curl \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt . @@ -25,6 +28,22 @@ RUN pip install --no-cache-dir -r requirements.txt COPY . . +# 2026-09-09 fix (real Railway outage): railway.json's own "deploy.startCommand" +# always runs `/app/bin/litestream ...` to wrap uvicorn (continuous SQLite +# replication), regardless of which builder actually produced the image. +# Adding this Dockerfile in PR #51 caused a real production deploy failure -- +# "The executable /app/bin/litestream could not be found" -- because Railway +# built from THIS file instead of nixpacks.toml (which is where litestream +# was previously installed, in its own [phases.litestream] block) even +# though railway.json pins "builder": "NIXPACKS". Installing the identical +# binary here (same version/URL as nixpacks.toml) makes this Dockerfile +# correct no matter which builder Railway or any other platform picks. +RUN mkdir -p /app/bin \ + && curl -L https://github.com/benbjohnson/litestream/releases/download/v0.3.13/litestream-v0.3.13-linux-amd64.tar.gz -o /tmp/litestream.tar.gz \ + && tar -xzf /tmp/litestream.tar.gz -C /app/bin \ + && chmod +x /app/bin/litestream \ + && rm -f /tmp/litestream.tar.gz + # Same placeholder pattern already proven in .github/workflows/ci.yml: # services/news_service.py's NewsService.__init__ only checks that # NEWS_API_KEY is *present* at import time -- it never calls the real