I’m technically shallow from a Railway systems standpoint and had GPT-5 draft the specifics for the support or guidance I am needing.  I appreciate any suggestions or guidance on this and apologize in advance for the lengthy read.

Context

• Project: n8n-mcp Core on Railway VPC, service “open-webui-mcpo” (Streamable HTTP MCP proxy).

• Source Repo: DC-AAIA/open-webui-mcpo (branch: main).

• Region: us-west2. One replica. Auth via HTTP Bearer.

• Relevant docs I’m instructing GPT-5 to use as its source of truth as part of a dedicated Abacus AI Project knowledge collection: DC-AAIA fork of Railway docs: https://github.com/DC-AAIA/railwayapp-docs

Observed behavior

• open-webui-mcpo service redeploys consistently reuse cached layers from a previous/original build version end-to-end, so intended code revision commits to my forked Dockerfile or other mcpo service files are not included in the redeploy builds. Build time ~9s. All Docker steps show “CACHED,” including:

  • COPY . /app

  • RUN uv venv "/app/.venv"

  • RUN uv pip install . && rm -rf ~/.cache

• I purposely changed the app code (FastAPI OpenAPI spec output) but the running service still serves the old OpenAPI. This indicates the redeployed image did not include my latest source.

• I do see a RUN echo "BUILD_REV=2025-08-14T17-35-00Z" > /build-rev.txt in the Dockerfile, but it is static and shows as CACHED in logs, so it does not invalidate anything downstream.

Questions

1. What’s the recommended/most reliable way on Railway to force a rebuild without cache for GitHub-based Docker builds? In the UI, should I use a “Clear build cache” or “Rebuild without cache” action for the service? If using the Railway CLI, which exact flag/command should I use for a no-cache rebuild? I’m deferring to the DC-AAIA Railway docs fork but want to confirm best practice from the Railway team / community.

2. Does the “Upstream Repo: Check for updates” control in the Source section affect builds from my connected repo? My understanding is it’s for syncing template updates, not for pulling the latest code from DC-AAIA/open-webui-mcpo (which the service already points to). Please confirm.

3. Are there any project-level cache settings I should verify (e.g., build cache scope or retention) that could be causing overly aggressive caching across builds for this service?

4. Any known pitfalls with ARG-based cache busters on Railway? GPT-5 recommended a plan to switch to:

   • Dockerfile
     ARG BUILD_REV
     RUN echo "BUILD_REV=${BUILD_REV}" > /build-rev.txt

   • And pass a new BUILD_REV per deploy (timestamp/sha) so COPY and pip install steps invalidate as expected.

Artifacts

• Build Logs excerpt (Aug 15, 2025): all steps “CACHED” including COPY and uv pip install; total build time 9.43 seconds.

• Deploy logs show app starts and connects to my MCP backend. /openapi.json returns, but expected code changes are not present.

Goal

• Confirm the simplest, Railway-approved path to force a fresh image when building from DC-AAIA/open-webui-mcpo:main, and ensure we’re not missing a quicker alternative to break the cache for this service.

Thanks in advance. Railway is a fantastic platform and support has been great for me, and I  want to ensure I stay aligned to Railway best practices.