Deploy and Host Medusa 2 on Railway

The Medusa commerce backend and its admin dashboard, with Postgres and Redis. Everything is pinned, migrations run before the new version takes traffic, and an administrator is created for you.

The dashboard is at /app. Log in with ADMIN_EMAIL and the generated ADMIN_PASSWORD from your service variables.

About Hosting Medusa 2

There are three Medusa templates on Railway, with 2869 failed deployments between them. The largest reports 12% health: it builds from medusajs/medusa-starter-default, the version 1 starter, while Medusa has been on 2.x for a long time. Its Postgres is :latest and its Redis is a Bitnami image, and Bitnami has closed its public tag catalogue, so that pull is no longer dependable and fails quietly.

This template is Medusa 2.18, written against the published packages, with every version pinned.

It is the backend and its admin. A storefront is a separate application talking to the Store API; deploy one when you need it and point it here.

Common Use Cases

The backend and admin for an online store, with a storefront deployed separately against the Store API.
Starting on Medusa 2 rather than the version 1 starter that the largest existing template still builds.
A Medusa backend with Redis-backed events, workflows and cache from the first deploy, instead of the in-memory defaults.

Dependencies for Medusa 2 Hosting

Deployment Dependencies

Medusa 2.18, built from ak40u/medusa-railway-starter (public)
Postgres ghcr.io/railwayapp-templates/postgres-ssl:18
Redis redis:8.6.5-alpine

Implementation Details

Five things that matter here:

Migrations run pre-deploy, not at build. The build container has no database. They run from .medusa/server: Medusa's build output is a separate application, and that catches people out.
The administrator is created on first boot from ADMIN_EMAIL and ADMIN_PASSWORD. medusa user fails when the account already exists, which is the normal outcome of every later deploy, so that failure is not allowed to fail the deploy.
Redis drives the event bus, the workflow engine and the cache. Without it Medusa uses in-memory versions: fine on a laptop, quietly wrong once there is more than one process.
All four @mikro-orm/* packages sit on one version. MikroORM refuses to start otherwise, and its error does not say which version it wants.
The build reuses one dependency tree. Medusa's build output has the same dependencies as the source; installing them a second time pushed the build past the platform's limit, so the root tree is linked instead.

Configuration

Nothing to fill in. JWT_SECRET, COOKIE_SECRET, the database password and the admin password are generated. CORS is *; narrow it once you have a storefront.

Verification

Deployed from this template: /health returns 200, the generated ADMIN_PASSWORD authenticates against /auth/user/emailpass and returns a token, a wrong password returns 401, and the admin dashboard at /app serves.

Why Deploy Medusa 2 on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Medusa 2 on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.