Shipping TanStack Start and Bun to Railway

Source: Dev.to

Problem

Railway’s Nixpacks autobuild detects Bun projects, but it can’t handle the sequence this site needs:

• prisma generate at build time
• Vite + the TanStack Start plugin
• a custom server.ts entry point
• prisma migrate deploy on boot

Teaching Nixpacks to orchestrate all of that is more complex than using a straightforward multi‑stage Dockerfile.

Solution

A four‑stage Dockerfile solves the problem:

1. Two parallel bun install stages – one installs all dependencies, the other installs only production‑only packages.
2. Build stage – runs prisma generate against a dummy DATABASE_URL.
3. Lean runtime stage – layers the generated Prisma client on top of the production node_modules.
4. Entrypoint – runs migrations before exec‑ing into Bun so the container’s PID 1 shuts down cleanly on Railway’s SIGTERM.

Dockerfile recipe (summary)

• Stage 1: FROM bun:latest AS deps-full → bun install (all deps).
• Stage 2: FROM bun:latest AS deps-prod → bun install --production.
• Stage 3: FROM deps-full AS build → set a dummy DATABASE_URL, run prisma generate, then build the Vite/TanStack Start bundle.
• Stage 4: FROM bun:slim AS runtime → copy node_modules from deps-prod and the generated Prisma client from build, add server.ts, and set the entrypoint that:
  1. Executes prisma migrate deploy
  2. exec bun server.ts

Railway‑side details

• Postgres reference variable: Wire the Railway‑provided Postgres URL to the app’s DATABASE_URL environment variable.
• Binding address: Explicitly bind the server to 0.0.0.0 so Railway can route traffic correctly.
• COPY order: Ensure the generated Prisma client is copied after the production node_modules so the runtime sees the correct client version.

Originally published at andreasbergstrom.dev — read the full post there.