Medusa Deployment: Railway vs Vercel vs VPS (2026)

Medusa deployment starts with a fact that disqualifies half the hosting market: the backend is a long-lived Node.js server, not a serverless function, and Medusa's deployment docs say so directly. This comparison takes the three destinations people actually shortlist (Railway, Vercel, and a bare VPS) and judges them against what Medusa requires, with every price checked at the source on August 27, 2026.

Full disclosure first: I run a production Medusa marketplace on Railway (10,000 products, 50 vendors, zero infrastructure incidents since launch), so I know one of these paths from the inside and the other two from evaluation. The full case study covers that build; this article is the deployment decision on its own.

What does Medusa actually require from a host?

Four things, and they filter the market before any pricing does:

1. A long-lived Node.js process. The docs are explicit that serverless does not qualify.
2. Two instances in production: one in server mode for requests, one in worker mode for background jobs, switched by MEDUSA_WORKER_MODE.
3. At least 2 GB of RAM. The docs' words are that your provider "must offer at least 2GB of RAM".
4. Redis, which in production backs four modules: caching, the event bus, the workflow engine, and locking.

Add PostgreSQL and an S3-compatible file store, and the true shape of "deploying Medusa" is five or six services rather than one.

One more thing worth knowing before you search for tutorials: the official docs currently list only Medusa Cloud, a general self-hosting guide, and a Vercel guide for the storefront. A dedicated Railway guide existed once; its old URL now redirects to a cloud-vs-self-hosting comparison that mentions Railway only in passing. So the Railway path below is assembled from the general guide plus my production setup; an official walkthrough to copy from does not exist.

Railway: the path I run in production

Railway's fit for Medusa comes down to one sentence: it runs long-lived processes with per-second billing and treats a multi-service project as the normal case. The whole stack (server, worker, PostgreSQL, Redis) lives in one project, deploys from one repository, and appears on one bill.

The setup has four load-bearing steps. Create PostgreSQL and Redis from templates, then two services from the same Medusa repository. The server service gets MEDUSA_WORKER_MODE=server and serves the admin; the worker gets MEDUSA_WORKER_MODE=worker with DISABLE_MEDUSA_ADMIN=true. Both need DATABASE_URL, REDIS_URL, COOKIE_SECRET, JWT_SECRET. The production build comes from npx medusa build, which per the build docs produces a standalone bundle in .medusa/server, and migrations run through a predeploy script executing medusa db:migrate before start. Smoke test: GET /health returns OK, admin answers at /app.

What that costs is arithmetic. Railway's current rates: memory at $0.00000386 per GB-second is about $10.14 per GB held for a full month, vCPU at $0.00000772 per second about $20.29 per fully-used core-month, egress $0.05 per GB, and the Hobby plan is $5 a month with $5 of usage included. Because billing follows actual consumption, an idle-heavy commerce backend costs less than the provisioned mental model suggests: a small shop calculates to roughly $15–25 a month, and my production marketplace backend runs $40–60. That one is the bill Railway actually charges.

Two things I have noticed from running it (experience, not benchmarks). Individual services build in two to three minutes and deploy in parallel, which makes ten-deploys-a-day iteration normal. And Railway ships an MCP server, so an AI coding agent can inspect services, deployments, and logs directly; I cover that workflow in the Medusa and AI agents guide.

Vercel: storefront yes, backend no

Vercel appears in this comparison because people keep asking, and the answer deserves precision rather than dismissal. For the Medusa backend, Vercel is the wrong shape: its compute is function-based with bounded execution (300 seconds by default, extendable to 800), and Vercel's own function docs state that functions are not meant for unlimited execution time. A commerce backend holding an event bus, scheduled jobs, and a workflow engine is exactly the workload that assumption excludes, which is why Medusa's deployment docs do not list Vercel as a server option.

For the storefront, the same docs make Vercel the documented recommendation: deploy the Next.js starter to a frontend host, keep the backend on a Node.js host. One footnote belongs in every honest version of that advice: Vercel's Hobby plan is restricted to personal, non-commercial use, so a commercial shop storefront starts at the Pro plan: $20 a month with $20 of usage credit included. A $20 line item is perfectly reasonable; it is just not the free tier people assume.

So Vercel gets a split decision: host the storefront there, keep the backend elsewhere.

VPS: cheapest compute, highest operations budget

The raw numbers make a VPS look unbeatable. Hetzner's CX23 (2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB of traffic included) costs €5.99 a month with the IPv4 address, and doubles Medusa's 2 GB requirement for a fifth of a typical PaaS bill. The CX33 at €8.99 gives 8 GB, enough to run server, worker, PostgreSQL, and Redis on one box with headroom.

The price you pay instead is a job description. On a VPS, you are the one installing and patching PostgreSQL and Redis, configuring the reverse proxy and TLS, wiring deploys, testing backups, and getting woken when a disk fills at 2 a.m. None of that is exotic for a team that already operates Linux servers; for such a team, Hetzner is a genuinely great answer. For a solo builder or a product team without ops experience, the €35 a month saved converts into hours at a terrible exchange rate. My own choice of Railway over a VPS was exactly this trade, made consciously: I wanted my maintenance hours going into the marketplace, not into the substrate.

A caveat these numbers deserve: I have not run Medusa on a Hetzner box in production. The prices above are from the published list, and the operations description comes from what running Linux servers generally involves, not from operating this particular stack on one. Railway is the only path in this article I can vouch for from the inside; the other two are priced and evaluated, not lived.

Can you switch later?

Yes, and that lowers the stakes of this whole decision. Medusa is a standard Node.js application over PostgreSQL: the production build is a self-contained bundle, the data is a Postgres dump away, and an S3-compatible image store like R2 works identically from any host. Moving from Railway to a VPS (or the reverse) is a redeploy plus a database restore rather than a migration project; nothing in the architecture marries you to the platform. The one direction that does cost real work is leaving a managed database with provider-specific extensions or moving the file store itself, which is a good argument for keeping images in a neutral bucket from day one. Pick the option that fits this year's team; the architecture will follow you to next year's.

The comparison in one table

Prices checked August 27, 2026, in each provider's listed currency. The fourth option, Medusa Cloud from $29 a month, is the managed path the docs recommend when you want no infrastructure at all; it trades control for operations, which is a fair trade for many teams.

When each option wins

Railway wins when you want the backend, worker, and databases on one platform with usage-based billing and near-zero ops. It is the default I recommend for solo builders and small product teams, and the one my own production bill documents. A VPS wins when Linux operations are already a competence in the room and infrastructure cost matters more than infrastructure time; Hetzner at €5.99 is the honest budget champion. Vercel wins the half it is designed for, the storefront, and should never carry the backend. And Medusa Cloud wins when the team wants to ship commerce logic and never think about worker modes at all; paying the platform to hold that pager is a legitimate strategy, not a failure of self-hosting ambition.

Really it is one question: whose time maintains the substrate? If the answer is "nobody we want to spend on this", stay managed: Railway or Medusa Cloud. If the answer is "our ops team, happily", the VPS math is real. All the surrounding decisions (which commerce platform at all, what the total build costs) live in the open source ecommerce field guide and the rest of the e-commerce series; the German version of this guide is here. The PoC Sprint exists for exactly this: your specific stack, decided against real requirements, in two weeks.