---
title: "Deploy Medusa 2 | Migrations Before Traffic, Admin on First Boot"
description: "Medusa 2 pinned. Migrations before traffic, admin created on first boot."
category: "Starters"
url: https://railway.com/deploy/medusa-2-or-migrat-1
---

# Deploy Medusa 2 | Migrations Before Traffic, Admin on First Boot

Medusa 2 pinned. Migrations before traffic, admin created on first boot.

**[Deploy Medusa 2 | Migrations Before Traffic, Admin on First Boot on Railway](https://railway.com/template/medusa-2-or-migrat-1)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/medusa-2-or-migrat-1/manifest.json

- **Creator:** Templates Guru
- **Category:** Starters

## Template content

### Redis

- **Image:** redis:8.6.5-alpine
- **Start command:** `/bin/sh -c 'redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes --bind 0.0.0.0 :: --protected-mode no'`

### Postgres

- **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18

### Medusa

- **Source:** https://github.com/ak40u/medusa-railway-starter
- **Public domain:** Yes

## Documentation

# 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](https://github.com/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.


## Similar templates

- [open-excalidraw](https://railway.com/deploy/open-excalidraw) — Self-hostable collaborative drawing built on Excalidraw
- [caring-vibrancy](https://railway.com/deploy/caring-vibrancy) — Deploy and Host caring-vibrancy with Railway
- [Appsmith](https://railway.com/deploy/appsmith-1) — Low-code platform for internal tools, dashboards, and admin panels.

Open this page in a browser: https://railway.com/deploy/medusa-2-or-migrat-1