Deploy a React + Express app to Railway

What you're actually deploying

A React + Express app has two halves with completely different runtime needs:

The approach in this guide is to run one service: Express serves the API and the built React files. One deploy, one domain, one bill, and no CORS configuration at all — because the frontend and API share an origin.

Splitting them across two services is a legitimate choice, but it buys you two deployments, a CORS policy to maintain and a second thing to pay for. Do it when the halves genuinely need to scale or ship separately, not by default.

Project structure

A monorepo with separate client and server folders keeps the two halves independent while staying a single repo and a single deploy:

myapp/
  client/            ← React + Vite frontend
    src/
    dist/            ← built output (after npm run build)
    package.json
    vite.config.js
  server/            ← Express backend
    index.js
    routes/
  package.json       ← root scripts that drive both

Root package.json scripts. The build and start pair is what the host will call:

{
  "scripts": {
    "build": "npm install --prefix client && npm run build --prefix client",
    "start": "node server/index.js",
    "dev": "concurrently \"npm run dev --prefix client\" \"nodemon server/index.js\""
  }
}

Using --prefix client rather than cd client && keeps the script working the same way locally and inside a build container.

Make Express serve the React build

In production Express serves the static bundle itself. Add this to server/index.js:

import express from 'express'
import path from 'path'
import { fileURLToPath } from 'url'

const __filename = fileURLToPath(import.meta.url)
const __dirname = path.dirname(__filename)

const app = express()

app.use(express.json())

// API routes first — they must win over the catch-all below
app.use('/api', yourApiRouter)

// Then the built React app
const clientDist = path.join(__dirname, '../client/dist')
app.use(express.static(clientDist))

// Anything that isn't an API route is handed to React Router
app.get('*', (req, res) => {
  res.sendFile(path.join(clientDist, 'index.html'))
})

Order matters. The app.get('*') catch-all is what makes a hard refresh on /dashboard work instead of 404 — but if you register it before your API routes it will swallow them too.

This is the same SPA-routing problem static hosts solve with a rewrite rule. If you want the background, we cover it host by host in fixing the React Router 404 on refresh.

Configure Vite so dev and production agree

In development the React dev server and Express run on different ports, so you proxy API calls to avoid CORS. In production they share an origin and no proxy is needed. Keep the proxy in client/vite.config.js:

export default {
  server: {
    proxy: {
      '/api': 'http://localhost:3001'
    }
  }
}

Then use relative URLs everywhere in your React code:

const response = await fetch('/api/users')

One line that works in both places: proxied to Express in development, served by Express in production. No environment-specific API base URL to manage, and no CORS policy to get wrong.

The one change almost everyone forgets

Every managed host — Railway, Render, App Platform, Fly, Heroku — assigns your app a port at runtime and passes it in as the PORT environment variable. An app hardcoded to 3001 binds to a port nothing is routed to, and you get a deploy that looks successful and serves nothing.

const PORT = process.env.PORT || 3001

app.listen(PORT, '0.0.0.0', () => {
  console.log(`Server listening on ${PORT}`)
})

Deploying to Railway

With the app itself ready, the deploy is mostly configuration. Railway builds from a connected Git repository, so after the first setup you deploy by pushing.

build:  npm run build
start:  npm start

Railway's dashboard changes shape from time to time, so treat the labels above as intent rather than exact button names — the six things that need to happen are stable even when the UI moves.

Adding Postgres

Most React + Express apps want a database, and this is where a platform like this earns its keep: add a Postgres instance to the same project and it becomes reachable from your service through an injected connection-string variable — no networking to configure, no separate provider to bill you.

import pg from 'pg'

const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
})

Reference the injected variable rather than copying the credentials into your own settings — if the database is later rotated or moved, a copied string goes stale and a reference doesn't.

Run migrations as part of your start command, or as a one-off from your machine against the same connection string. Avoid running them in the build step: builds can be retried or run concurrently, and migrations should not be.

Deploying updates

After the first setup there's no deploy script to maintain:

git push origin main

The push triggers a build, and the new version replaces the old one once it starts successfully. A failed build leaves the running version alone — which is the main practical advantage over deploying to a server by hand, where a broken build is discovered by your users.

When Railway isn't the right answer

This setup is not Railway-specific — the app runs anywhere that can execute a Node process. Three cases where something else fits better:

Troubleshooting

Frequently asked questions