deploy: run a real production server, not langgraph dev

The Railway service has been running LangGraph's development server in
production. `langgraph dev` holds threads and runs in memory via
langgraph-runtime-inmem, so every deploy and every restart drops whatever was
in flight — the AlphaFRS poller then watches the thread disappear instead of
completing. It also stamps api_variant=local_dev on every log line and runs a
filesystem watcher (207 "changes detected" in a 4-minute window, recorded in
alphaFRS docs/notes/2026-08-02-competitor-intel-iteration.md, open item 2).

The fix is not LangSmith Deployment. Of the four options on
docs.langchain.com/langsmith/deployment, only Standalone Server can run on
Railway and it needs an Enterprise licence; Cloud needs Plus at $39/seat and
is not Railway at all. None of it is required, because the gateway already
implements the LangGraph Platform runs API in-process
(app/gateway/routers/thread_runs.py) — which is exactly what upstream's own
production compose relies on: docker/docker-compose.yaml runs nginx, frontend
and gateway, no LangGraph server anywhere, with
DEER_FLOW_CHANNELS_LANGGRAPH_URL pointed back at the gateway.

The langgraph dev process was never load-bearing here. Every endpoint AlphaFRS
calls — POST /api/threads, POST /api/threads/{id}/runs,
GET /api/threads/{id}/runs/{run_id}, GET /api/threads/{id}/state — is a gateway
route. Only the IM channels service talks to the configured LangGraph URL, and
AlphaFRS does not use channels.

So: drop it, and get durability from Postgres instead.

- config.yaml: database.backend sqlite -> postgres reading $DATABASE_URL.
  SQLite sat on a container filesystem Railway discards on every deploy, which
  made "persistent" checkpoints a fiction.
- config.yaml: run_events.backend memory -> db. With memory, a run's history
  lived in one worker's process and a status lookup landing on the other worker
  404'd — the condition patch 0005 worked around at the API level.
- entrypoint: gateway only, via exec so Railway's signals reach uvicorn rather
  than a supervising shell. Fails fast with a clear message if DATABASE_URL is
  unset, instead of starting against an empty postgres_url. DEER_FLOW_CONFIG_PATH
  is now pinned rather than relying on the legacy monorepo fallback in
  app_config.py to find /app/config.yaml.
- entrypoint: --workers 2. Shared Postgres state is the precondition that makes
  more than one worker safe; the comment says so, next to the flag.
- Dockerfile: uv sync --extra postgres, without which the checkpointer factory
  raises ImportError at startup.

Verified before commit: bash -n on the entrypoint; config.yaml loads through
DeerFlow's own AppConfig and reports backend=postgres, run_events=db,
checkpointer=None (so the unified `database` section drives both); and
`uv sync --extra postgres --dry-run` installs asyncpg,
langgraph-checkpoint-postgres, psycopg, psycopg-binary and psycopg-pool from
the existing lockfile with no re-resolution.

Not yet verified, and only observable on Railway: that a run survives a service
restart. That is the whole point of the change and is the first thing to test
after deploy.

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

Author: Christopher-hughes-cab

Dockerfile.railway

@@ -1,6 +1,9 @@
 # DeerFlow — Railway production Dockerfile
-# Runs gateway (port 8001) + langgraph (port 2024) behind a supervisor entrypoint.
-# Railway routes external traffic to $PORT (gateway).
+# Runs the gateway (port 8001) as the container's only process. The gateway
+# serves the LangGraph-compatible API itself; there is no separate LangGraph
+# server. See entrypoint.railway.sh for why.
+#
+# Requires DATABASE_URL at runtime (config.yaml sets database.backend=postgres).
 #
 # Build: docker build -f Dockerfile.railway -t deerflow-railway .
 # Run:   docker run -p 2026:8001 --env-file .env deerflow-railway
@@ -41,16 +44,20 @@ WORKDIR /app
 COPY backend ./backend
 RUN mkdir -p /app/skills/custom /app/skills/public
 
-# Install Python deps
-RUN cd backend && UV_INDEX_URL=${UV_INDEX_URL:-https://pypi.org/simple} uv sync
+# Install Python deps.
+# --extra postgres pulls deerflow-harness[postgres] (asyncpg,
+# langgraph-checkpoint-postgres, psycopg[binary], psycopg-pool). Required
+# because config.yaml sets database.backend=postgres; without it the gateway
+# raises ImportError from the checkpointer factory at startup.
+RUN cd backend && UV_INDEX_URL=${UV_INDEX_URL:-https://pypi.org/simple} uv sync --extra postgres
 
 # Copy entrypoint + production config
 # config.yaml is committed past .gitignore (-f) and is the live Railway config.
 COPY entrypoint.railway.sh /app/entrypoint.sh
 COPY config.yaml /app/config.yaml
 RUN chmod +x /app/entrypoint.sh
 
-# Railway injects $PORT — gateway listens on it, langgraph on 2024 internally
+# Railway injects $PORT — the gateway is the only process and listens on it
 ENV PORT=8001
 EXPOSE 8001
 

config.yaml

@@ -979,9 +979,17 @@ skill_evolution:
 # database:
 #   backend: postgres
 #   postgres_url: $DATABASE_URL
+# AlphaFRS (Railway): postgres, not sqlite. The container filesystem is
+# discarded on every deploy and restart, so a sqlite file loses runs in flight
+# — the AlphaFRS poller then sees the thread disappear instead of completing.
+# It is also what makes >1 uvicorn worker safe: workers share run state through
+# Postgres rather than each holding their own. DATABASE_URL is supplied
+# per-environment by the Railway Postgres service, so staging and production
+# share this one baked config.
 database:
-  backend: sqlite
-  sqlite_dir: .deer-flow/data
+  backend: postgres
+  postgres_url: $DATABASE_URL
+  pool_size: 5
 
 # ============================================================================
 # Run Events Configuration
@@ -996,8 +1004,12 @@ database:
 #   backend: memory
 #   max_trace_content: 10240    # Truncation threshold for trace content (db backend, bytes)
 #   track_token_usage: true     # Accumulate token counts to RunRow
+# AlphaFRS (Railway): db, not memory. With `memory` a run's history lives in
+# one worker's process, so a status lookup landing on the other worker 404s —
+# the problem patch 0005 worked around at the API level. The db backend shares
+# it through the `database` section above.
 run_events:
-  backend: memory
+  backend: db
   max_trace_content: 10240
   track_token_usage: true
 

entrypoint.railway.sh

@@ -1,56 +1,66 @@
 #!/usr/bin/env bash
 # DeerFlow — Railway entrypoint
-# Starts langgraph dev server (port 2024) and the gateway (port $PORT / 8001).
-# Both processes are supervised; if either exits, the container exits.
+# Starts the gateway (port $PORT / 8001) as the container's only process.
+#
+# There is deliberately NO LangGraph server here. The gateway implements the
+# LangGraph Platform runs API in-process (app/gateway/routers/thread_runs.py),
+# which is what upstream's own production compose does — docker-compose.yaml
+# runs nginx + frontend + gateway and no LangGraph server at all, with
+# DEER_FLOW_CHANNELS_LANGGRAPH_URL pointed back at the gateway.
+#
+# This used to run `langgraph dev` alongside the gateway. That is the
+# DEVELOPMENT server: it stamps api_variant=local_dev, watches the filesystem
+# for hot reload, and holds threads and runs in memory via
+# langgraph-runtime-inmem. Nothing AlphaFRS calls was ever served by it — every
+# endpoint in alphaFRS backend/deerflow.py hits the gateway's /api/threads
+# routes — so it was pure overhead and a misleading log signature.
+#
+# Durability now comes from Postgres (config.yaml: database.backend=postgres,
+# run_events.backend=db), not from a LangGraph server. If you find yourself
+# wanting to add one back, note that the supported production LangGraph servers
+# are LangSmith Cloud (Plus, $39/seat) and Standalone Server (Enterprise
+# licence) — neither is needed for this architecture.
 
 set -euo pipefail
 
 # ── Config ───────────────────────────────────────────────────────────────────
 GATEWAY_PORT="${PORT:-8001}"
-LANGGRAPH_PORT=2024
 BACKEND_DIR="/app/backend"
 
 # config.yaml is baked into the image at build time (see Dockerfile.railway).
+# DATABASE_URL is injected by Railway from the Postgres service and expanded by
+# config.yaml's native $ENV_VAR support. Fail fast rather than let the gateway
+# start against an empty postgres_url and surface as a confusing runtime error.
+if [ -z "${DATABASE_URL:-}" ]; then
+  echo "[entrypoint] FATAL: DATABASE_URL is unset."
+  echo "[entrypoint] config.yaml sets database.backend=postgres and reads \$DATABASE_URL."
+  echo "[entrypoint] Attach the Railway Postgres service to this environment."
+  exit 1
+fi
 
-# ── Start langgraph ───────────────────────────────────────────────────────────
-echo "[entrypoint] Starting langgraph on port ${LANGGRAPH_PORT} …"
 cd "${BACKEND_DIR}"
-.venv/bin/langgraph dev \
-  --host 0.0.0.0 \
-  --port "${LANGGRAPH_PORT}" \
-  --no-browser \
-  &
-LANGGRAPH_PID=$!
 
-# ── Wait for langgraph to be ready ───────────────────────────────────────────
-echo "[entrypoint] Waiting for langgraph to be ready …"
-for i in $(seq 1 30); do
-  if curl -sf "http://localhost:${LANGGRAPH_PORT}/ok" > /dev/null 2>&1; then
-    echo "[entrypoint] langgraph is ready."
-    break
-  fi
-  sleep 2
-done
+# Pin the config path. Without this it still resolves, but only by falling
+# through to the "legacy monorepo" candidate list in app_config.py, which finds
+# /app/config.yaml two levels up from cwd. Being explicit means a missing or
+# misplaced config fails at startup with a clear error instead of silently
+# resolving somewhere else after a layout change.
+export DEER_FLOW_CONFIG_PATH="/app/config.yaml"
+
+# The IM channels service talks to the LangGraph-compatible API. That is us.
+export DEER_FLOW_CHANNELS_LANGGRAPH_URL="http://localhost:${GATEWAY_PORT}/api"
+export DEER_FLOW_CHANNELS_GATEWAY_URL="http://localhost:${GATEWAY_PORT}"
 
 # ── Start gateway ─────────────────────────────────────────────────────────────
+# exec: the gateway becomes PID 1 so Railway's stop/restart signals reach uvicorn
+# directly instead of a shell that would have to forward them.
+#
+# --workers 2 is safe only because run state is shared through Postgres. Do not
+# raise workers (or railway.toml's numReplicas) while database.backend is
+# sqlite or memory — each worker would keep its own runs and status lookups
+# would 404 depending on which one answered.
 echo "[entrypoint] Starting gateway on port ${GATEWAY_PORT} …"
-.venv/bin/python -m uvicorn app.gateway.app:app \
+exec .venv/bin/python -m uvicorn app.gateway.app:app \
   --host 0.0.0.0 \
   --port "${GATEWAY_PORT}" \
-  &
-GATEWAY_PID=$!
-
-# ── Supervisor loop ───────────────────────────────────────────────────────────
-echo "[entrypoint] Both services started (langgraph PID=${LANGGRAPH_PID}, gateway PID=${GATEWAY_PID})."
-
-wait_any() {
-  while kill -0 "${LANGGRAPH_PID}" 2>/dev/null && kill -0 "${GATEWAY_PID}" 2>/dev/null; do
-    sleep 5
-  done
-}
-
-wait_any
-
-echo "[entrypoint] A service exited — shutting down."
-kill "${LANGGRAPH_PID}" "${GATEWAY_PID}" 2>/dev/null || true
-exit 1
+  --workers 2