Deploy and Host Medusa on Railway

Medusa is an open-source commerce platform, often used as a Shopify alternative: products, inventory, carts, orders, customers, regions and taxes behind an API, with an admin dashboard. This template runs Medusa 2.21.2 with its admin and Medusa's official Next.js storefront, on Postgres and Redis.

About Hosting Medusa

The template builds Medusa's official starter, dtc-starter, at a pinned commit (it has no releases). Medusa's older Next.js starter is archived; dtc-starter is the one Medusa points to now.

What happens on deploy:

The backend runs its migrations on every start. On an empty database they also seed a starter store: a Europe region (GB, DE, DK, SE, FR, ES, IT) in EUR and USD, shipping options, a stock location and four demo products you can delete in the admin.
The admin account is created from MEDUSA_ADMIN_EMAIL and a generated MEDUSA_ADMIN_PASSWORD. Medusa has no public admin sign-up, so nobody else can claim the store.
The storefront needs a publishable API key when it's built, which usually means copying it from the admin and rebuilding. Here the key is generated at deploy (MEDUSA_PUBLISHABLE_KEY), the storefront is built with it, and the backend sets its store key to that value on every start.
The storefront's product, collection and category pages render on request instead of at build time, so it builds before the backend has ever run and new products show up without a rebuild.
Redis handles caching, events, workflows and locking. Uploaded images go to a volume and are served by the backend at /static. The backend's heap is capped at 512 MB so it fits a 1 GB service.

Before publishing I tested it on Railway. The backend answered /health and served the admin at /app, and the admin signed in with the generated password. The store API, called with the generated publishable key, listed the four seeded products, and the storefront rendered the Medusa Sweatshirt's product page. An image uploaded through the admin API was served from /static. After restarting all four services the same checks passed and the image was still there.

Memory at idle: backend 0.34 GB, storefront 0.10 GB, Postgres 0.07 GB, Redis 0.01 GB. That's about $5 a month on Railway's usage pricing.

Common Use Cases

An online store you own end to end, without per-sale platform fees
A headless commerce backend for your own frontend or mobile app, using the storefront as a reference
Multi-region selling with separate currencies, tax rates and shipping options

Dependencies for Medusa Hosting

Nothing beyond the template for a test store. To take real payments, add a payment provider such as Stripe: that's a change to the backend's medusa-config.ts, so copy the two folders below into your own repository and point the services at it.

Deployment Dependencies

Medusa: https://github.com/medusajs/medusa
dtc-starter (backend and storefront): https://github.com/medusajs/dtc-starter
Docs: https://docs.medusajs.com
What this template adds: https://github.com/dektionstudio/railway-template-images (folders medusa and medusa-storefront)

Implementation Details

STOREFRONT_URL         # your shop
MEDUSA_ADMIN_URL       # the admin; sign in with MEDUSA_ADMIN_EMAIL / MEDUSA_ADMIN_PASSWORD
MEDUSA_BACKEND_URL     # store API: send x-publishable-api-key: $MEDUSA_PUBLISHABLE_KEY

The storefront has the backend URL and the publishable key built in. After adding a custom domain, update STORE_CORS and AUTH_CORS on the backend and redeploy the storefront.

Why Deploy Medusa on Railway?

The backend, storefront, database and Redis come up together and talk over Railway's private network, with the store already set up and an admin login waiting. You pay for what the store uses, not a share of each sale.