Remix hosting — 7 options compared

Remix has no incremental cache to get wrong, which removes the hardest part of self-hosting a React framework. What it has instead is a loader on every route running on every request — so the thing that decides your hosting is how far that loader has to reach for data.

Last updated 7 August 2026

Remix is a server-rendering framework with an unusually small hosting surface. There is no incremental static regeneration to keep consistent across replicas, no built-in image optimizer consuming CPU on your instance, and no build-time page generation to schedule. A Remix app is a Node server that renders HTML, which means almost everything on this page can run it without ceremony.

The naming has moved, and it is worth stating plainly: Remix v2 became React Router v7 in framework mode, and the Remix name now points at a separate future direction. Everything on this page applies to both — the deployment model is identical, and if you are running React Router v7 in framework mode, read "Remix" throughout as your app.

Because the framework does so little at build time, the deciding factor is data locality. Every navigation runs loaders, every loader queries something, and the user waits for the slowest one. An app whose database is one network hop away behaves very differently from the same code calling a database across the public internet — and that difference is worth more than the price column on most of these platforms.

The short version: Vercel and Render are the easiest starts, Fly.io is the cheapest way to sit close to users, and Granite — our own platform — fits when the loaders should be talking to a database in the next box rather than across the internet. If the app is mostly static marketing pages, several options here are cheaper than we are and the table shows it.

At a glance

Sorted by entry price. Every provider here can build and run a Remix service; the columns are what separates them.
ProviderFrom /moFree tierManaged DBPersistent diskDeploy from
Vercel$0 / $20yes (non-commercial)via marketplaceGit
Fly.io~$2Postgres (unmanaged app)Dockerfile, buildpack
Railway$5yes ($1 credits)Git, Dockerfile, template
Render$7yes (spins down)Git, Dockerfile
Granite$9from AdvancedGit, Docker image
Koyeb$29limitedServerless PostgresGit, Dockerfile
Google Cloud Runusage-basedyes (monthly allowance)via Cloud SQLno (use GCS)Container image

Entry prices as published by each provider on 7 August 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.

PaaS, serverless or a plain VPS?

Pick the category before you pick the provider — it decides more than the logo does.

Remix is easier to self-host than Next.js, and it is worth saying why, because it changes which category makes sense. There is no incremental cache to share between replicas, no image optimizer eating your CPU, and no divergence between what runs on the framework's own platform and what runs anywhere else. A Remix server is an ordinary Node process. That makes a managed platform an unremarkable, boring choice — which is the highest compliment available in hosting.

Serverless works, and Node's fast start makes it far more reasonable than it is for an interpreted back end. The caution is architectural rather than technical: a framework that renders on every request pays the meter on every request, and a request-driven platform tends to buffer responses, which is precisely what streaming and deferred data are designed to avoid.

A managed platform with the database in the same project is the shape that suits this framework best. Loaders are chatty by design — that is the point of the nested-route data model — so the round trip between the server and the database happens several times per navigation. Removing the public internet from that path is a bigger win than any instance-size decision you will make.

Where should the Remix server run?

Loaders query a database on most navigations — the normal case

Platform with the database beside it

Every loader round trip stays inside a private network instead of crossing the internet.

Granite · Railway · Render

Marketing site or docs, little data, previews per pull request matter most

Vercel

Push to deploy, previews included, at $20 per seat once it stops being personal.

Vercel

Users spread across continents and latency is the product

Multi-region

Servers near users — worth it only if the data is near them too.

Fly.io · Koyeb

Note what is missing compared with the Next.js version of this question: there is no cache-coherence branch, because there is no incremental cache.

The options

Prices as published by each provider on the date above. Check them before you commit — they move.

Vercel

Best for
Getting a Remix app online with previews per pull request and no infrastructure decisions.
Pricing
Hobby is free forever but intended for personal, non-commercial projects. Pro is $20 per team member per month, including $20 of usage credit, with pay-as-you-go beyond it.
  • Deploys a Remix or React Router app from a Git push with no adapter configuration to reason about.
  • Preview deployments per pull request are excellent and genuinely hard to replicate elsewhere.
  • The CDN in front of your static assets is included rather than assembled.
  • Hobby is for personal, non-commercial projects, so anything real starts at $20 per team member per month.
  • Usage-based function and bandwidth pricing, which for a framework that renders on every request means the meter runs on every navigation.
  • The database lives somewhere else, so every loader pays for a round trip across the public internet — the cost Remix's architecture is most sensitive to.

Fly.io

Best for
Putting the server close to users on a small budget, with the database in the same region.
Pricing
Pay as you go. The smallest shared-cpu-1x machine with 256 MB RAM works out at roughly $2.02/month, billed per second.
  • Multi-region deployment and Anycast routing, which matters because every page view is server-rendered rather than served from a cache.
  • The cheapest machines are genuinely usable — a Node server rendering Remix has a small, flat baseline.
  • Takes your Dockerfile, so the Node version and the adapter are yours to pin.
  • Postgres is a Fly app you run and back up yourself.
  • Multi-region only helps if the data is nearby too — a server in Sydney reading a database in Frankfurt is slower than one server next to its database.
  • No free tier for new organisations since October 2024.

Railway

Best for
Getting the app and its database running together in one project quickly.
Pricing
Hobby is $5/month including $5 of usage credits; Pro is $20/month per workspace including $20 of credits. A free plan gives $1 of monthly credits, and there is a 30-day trial.
  • Detects a Node project and builds it without configuration.
  • Postgres and Redis sit in the same project and are reachable privately, which is exactly what loaders want.
  • A free plan and a 30-day trial for evaluation.
  • Usage-based billing on top of the base fee is hard to forecast.
  • No CDN of its own, so client bundles and images want one in front for anything traffic-heavy.

Render

Best for
A predictable monthly bill for a straightforward server-rendered app.
Pricing
Free web services are available but spin down after 15 minutes without traffic. The cheapest paid instance, Starter, is $7/month for 0.5 vCPU and 512 MB RAM.
  • A real free tier for evaluating, and simple fixed instance pricing afterwards.
  • Managed Postgres, Redis, cron jobs and workers in one account.
  • Static assets are served through a CDN without extra setup, which covers the client build.
  • Free services spin down after 15 minutes idle, and a server-rendered app has no cached HTML to fall back on while it wakes.
  • Fixed instance sizes mean scaling is a step change rather than a slider.

Granite

Best for
An app whose loaders should reach the database over internal DNS rather than the open internet.
Pricing
Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
  • Postgres or MySQL, Valkey and S3-compatible storage run in the same project as the app, so a loader's query is a local hop rather than a public round trip — the single biggest lever on Remix latency.
  • Runs your own image, so the Node version, the adapter and the server entry are yours to pin.
  • Background workers and cron jobs are first-class for the work loaders should not be doing.
  • Flat plan pricing with usage credits, so a busy week changes your graphs and not your invoice.
  • No free tier — the cheapest way in is $9/month.
  • No global edge network: you choose a region, and visitors far from it pay the latency on every navigation.
  • Preview environments per pull request are not part of the workflow the way they are on Vercel.

Koyeb

Best for
Edge presence with scale-to-zero for an app that is idle much of the day.
Pricing
The Pro plan is $29/month; Scale is $299/month. Serverless Postgres has a small free allowance.
  • Edge locations included rather than sold separately.
  • Node cold starts are quick enough that scale-to-zero is tolerable, unlike heavier runtimes.
  • The highest entry price of the managed options here.
  • Waking an instance and then running loaders against a distant database compounds two latencies on the same request.

Google Cloud Run

Best for
Bursty traffic where an idle app should cost nothing and you are already inside GCP.
Pricing
No monthly fee. You pay per request and per resource-second, with a monthly free allowance. Cloud SQL and networking are billed separately.
  • Scales to zero and has effectively no ceiling.
  • Takes any container, so a Node build with your chosen adapter deploys unchanged.
  • Per-request billing suits spiky traffic well.
  • Response streaming is constrained by the platform's request model, which undercuts one of the framework's better features.
  • No persistent disk, so uploads and any local cache have to move to a bucket before the first deploy.
  • Database, CDN and secrets are separate products you assemble and bill separately.

What a Remix app actually needs from a host

The requirements that matter for Remix are different from the ones every generic hosting listicle repeats.
Remix-specific criteria
The framework asks less of a host than most, so the list is short — but every item on it is something people discover after deploying rather than before.
The adapter decides the runtime
Remix builds against a server adapter: Node with Express or the built-in server, or an edge runtime such as Cloudflare Workers. That choice determines which APIs your loaders may use — the edge runtimes have no Node built-ins and many database drivers simply do not run there. Pick the adapter for the platform first, not after the code is written.
No response buffering
Streaming SSR and deferred loader data only help if the platform forwards bytes as your server produces them. A proxy that buffers the whole response — common on request-driven serverless — turns streaming into a slower version of ordinary rendering, because now nothing arrives until everything has. Test it with a deliberately slow deferred loader before you rely on it.
Loader latency is the product
Every navigation runs the loaders for every matched nested route, in parallel, and the page waits for the slowest. Ten milliseconds of database latency becomes tens of milliseconds per page view. This is the strongest argument for putting the app and its database in the same project rather than connecting to a database service across the internet.
Client assets belong on a CDN
The build produces a fingerprinted client bundle that never changes for a given filename, so it should be served with a long immutable cache from a CDN, while the HTML your server renders must not be cached at all. Platforms differ in how much of that they do for you; getting the two mixed up is the classic cause of a stale app shell fetching modules that no longer exist.
Session storage across replicas
Cookie sessions are signed and self-contained, so they work anywhere with a stable secret. Anything server-side — a database or Redis session store — needs shared storage the moment you run more than one instance. Decide before scaling, not after users start getting logged out at random.
Small, flat memory profile
One Node process rendering HTML idles around a hundred megabytes and stays remarkably steady, since there is no pool of worker processes each holding a copy of the framework. The cheap tiers that stop being realistic for Rails or Django remain realistic here — size for concurrency and rendering peaks rather than for a large baseline.
Uploads and the filesystem
The container filesystem is discarded on deploy and not shared between replicas. Anything a user uploads belongs in object storage from the first commit, and the framework gives you no default that papers over this.

So which should you pick?

A marketing site or docs with light data needs. Vercel. Push to deploy, previews per pull request, and the data locality argument does not apply when there is barely any data.

A conventional app with a database, on a predictable bill. Render. A free tier to evaluate, fixed instance pricing afterwards, and managed Postgres in the same account.

Loaders that query on every navigation. This is where we would argue for Granite. Postgres or MySQL, Valkey and S3-compatible storage sit in the same project as the app and are reached over internal DNS, so the several loader round trips a nested route tree makes per navigation stay inside a private network. For a framework whose latency is dominated by data fetching, that is the single most useful thing a platform can do. Flat plans from $9/month with $15 of usage credits.

An audience spread across continents. Fly.io — with the honest caveat that servers near users only help if the data is near them too, which usually means read replicas and a real plan for writes.

Weighing it against the other React framework? The Next.js hosting comparison covers the same platforms with a much longer list of caveats, and the app platform page covers building from Git, prebuilt images, workers and cron jobs.

Hosting for other stacks

Go hosting

Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.

Django hosting

Seven options weighed on the things Django actually needs: media storage, a real Postgres, Celery workers and enough memory for gunicorn.

Next.js hosting

Vercel and six alternatives, weighed on the things that actually break when you self-host: ISR across replicas, image optimization and build-time env vars.

Rails hosting

Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.

Laravel hosting

Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.

FastAPI hosting

Six platforms weighed on what an ASGI service actually needs: worker processes, connections that stay open, and a database pool that does not multiply out of control.

Flask hosting

Seven options for the framework that ships no opinions — weighed on the WSGI server you have to bring, the session key you must keep stable, and the extensions that decide the rest.

Symfony hosting

Six platforms weighed on the things Symfony assumes: a warmed cache built at build time, Messenger workers that restart on deploy, and Doctrine migrations that run exactly once.

Spring Boot hosting

Six platforms weighed on what the JVM actually asks for: memory it is allowed to use, a container that knows its own limits, and a start-up you can afford to repeat.

Docker hosting

Six places to run a container image, compared on what actually bites: architecture mismatches, registry access, signal handling and the volume you assumed would still be there.

Static site hosting

Five ways to serve HTML that is already written — and an honest note about which of them we are not the right answer for.

Remix hosting questions

More questions? Email us at support@granite.so

Be first in line for updates
and special pricing
Get early access to new features and exclusive discounts delivered straight to your inbox