Deploy on Railway

Verticals share the project’s Postgres and Redis and read the market feed through @denpa/sdk. They hold no database of their own.

railway add --service <name>                              # create the empty service
railway up --ci --service <name> -m "deploy <name>"       # build + deploy (shared railway.toml)
railway domain --service <name>                           # public URL

Wire the monorepo switch

Both files branch on RAILWAY_SERVICE_NAME:

• railway.toml — add <name>) exec pnpm --filter @denpa/<name> start ;; to the start command.
• scripts/railway-build.sh — add a <name>) case that builds @denpa/realtime, @denpa/types, @denpa/sdk-core, @denpa/sdk, @denpa/app-config, @denpa/ui, then exec pnpm --filter @denpa/<name> build.

Environment

Var	Notes
NEXT_PUBLIC_API_URL	point the vertical at a different backend; defaults to Denpa production
DENPA_BASE_URL	hub for writes and receipt links (default https://denpa.ai)
PROGRAM_CLOCK_URL	optional — only to run your own clock instance
BUILD_SHA	CLI deploys carry no git SHA; set it so /api/version reports the commit

No dots in Railway variable names.

Gotchas that have burned forks

• A deploy that fails in under 30 seconds is lockfile drift: run pnpm install --lockfile-only and commit.
• @denpa/db must be built before a Next build that imports it.
• NEXT_PUBLIC_* values are inlined at build time; changing them means rebuilding.
• Custom domains: Railway CNAMEs unproxied.
• Verify a deploy by its runtime status and /api/version buildTime, not by a SHA that reads local.