Where should db:migrate run?

In a release phase: once per deploy, after the build succeeds and before the new version starts serving. Every platform in this comparison provides one, under names like release command or pre-deploy hook. The tempting alternative — putting it in the container's start command — breaks as soon as you run more than one instance, because each replica runs the same migrations at the same time against the same schema.

Do I still need Redis for Rails background jobs?

Not necessarily. Rails 8 ships Solid Queue, which stores jobs in your existing database. For most applications that is enough, and it removes a whole managed service from the bill and from the list of things that can break. Sidekiq is still the right answer at higher throughput or when you rely on its ecosystem, and it does need Redis or Valkey. Either way the worker is a separate long-running process built from the same image as the web app.

Is Kamal a real alternative to a platform?

Yes, and it is unusual in that the framework ships it. Kamal builds your image, deploys it to servers you rent, performs zero-downtime rollovers and arranges TLS. On a small VPS it produces a genuinely production-grade setup for a few euros a month. What it does not do is take responsibility off you. Kernel updates, Postgres backups and their restore path, monitoring and being the person on call all remain yours. That is the actual trade — not features, but who gets woken up.

Where do Active Storage files go in production?

Object storage, configured through the S3 service in storage.yml. The container filesystem is discarded on every deploy and is not shared between instances, so local disk loses attachments in ways that look random from the outside. A persistent volume works if you are certain you will only ever run one instance. Object storage with a CDN in front is the option that keeps working when that assumption changes.

How much memory does a Rails app need?

Size it by Puma workers rather than by traffic. Each worker holds a full copy of the loaded application, so memory grows with the worker count and stays roughly flat as requests increase; threads inside a worker are comparatively cheap. In practice the smallest tiers on most platforms hold one modest worker. Start conservatively, watch real usage under real load, and add workers deliberately rather than provisioning for a peak you have not measured.

Ruby on Rails Hosting: 6 Options Compared (2026) • Granite.so

Last updated 3 August 2026

Rails deployment stopped being hard some years ago, and the interesting question moved. It is no longer whether a host can run Ruby — they all can — but whether the platform models the things Rails assumes: somewhere to run migrations exactly once per deploy, a long-running process for jobs, and object storage that Active Storage can point at.

There is also a genuinely different answer available here that other stacks do not have. Kamal ships with Rails and deploys containers to plain servers you rent yourself, with zero-downtime rollouts and automatic TLS. It is a serious option, it is cheap, and it means the honest comparison is not just platform against platform but platform against a VPS you drive with a tool the framework already gives you.

The short version: Render and Railway are the smoothest managed starts, Kamal on a VPS is the cheapest credible production setup if you enjoy owning the machine, and Granite — our own platform — fits when you want the Postgres, the job runner and the bucket in one project without becoming a sysadmin.

At a glance

Sorted by entry price. Every provider here can build and run a Rails service; the columns are what separates them.

Provider	From /mo	Free tier	Managed DB	Persistent disk	Deploy from
Fly.io	~$2		Postgres (unmanaged app)		Dockerfile, buildpack
Railway	$5	yes ($1 credits)			Git, Dockerfile, template
Render	$7	yes (spins down)			Git, Dockerfile
Granite	$9			from Advanced	Git, Docker image
Koyeb	$29	limited	Serverless Postgres		Git, Dockerfile
Google Cloud Run	usage-based	yes (monthly allowance)	via Cloud SQL	no (use GCS)	Container image

Entry prices as published by each provider on 3 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.

Kamal and a VPS deserve first mention here, because Rails ships the tool. Kamal builds your image, pushes it to servers you rent, does zero-downtime rollovers and handles TLS. On a €5 box that is a genuinely production-grade setup for less than any managed platform. What you keep is the responsibility: kernel updates, Postgres backups you have actually tested restoring, and being the person who gets up when the machine does not come back.

A managed platform buys exactly that responsibility off you. For Rails the valuable part is rarely the web tier — it is managed Postgres with backups, a place for jobs, and a release phase that runs migrations once instead of once per replica.

Serverless is the weakest fit of the three. Rails boots in seconds, so scale-to-zero puts that wait in front of a real visitor, and the framework expects a long-running process for jobs anyway. It can suit an internal tool that is idle most of the day; it is a poor default for anything public.

Where should Rails run?

You are happy owning a server, and price per gigabyte matters most

Kamal on a VPS

Zero-downtime deploys and TLS on a €5 box — you own backups and uptime.

Hetzner · DigitalOcean · Any VPS

You want managed Postgres, a job runner and storage without operating them

Managed platform

Web, worker and scheduler deploy together; migrations run in a release phase.

Granite · Render · Railway

Internal tool, idle most of the day, no user-facing latency budget

Serverless

Free while asleep, at the cost of a seconds-long wake-up.

Cloud Run · Koyeb

Rails is the one stack where a plain VPS is a first-class answer rather than a fallback — because the framework ships the deployment tool.

The options

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

Fly.io

Best for: Teams who want several regions and are content to run Postgres themselves.
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 with Anycast routing, which suits an app with a geographically spread audience.
Takes your Dockerfile, and Rails 8 generates a production-ready one for you.
Per-second billing and cheap small machines.

Postgres is a Fly app you operate and back up — for Rails, where the database is the application, that is a real commitment rather than a detail.
The cheapest machines are too small for a useful Puma worker set.
No free tier for new organisations since October 2024.

Railway

Best for: Standing up Rails, Postgres and Redis together in one afternoon.
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.

Templates cover the full Rails stack including Postgres and Redis for Sidekiq.
Services in a project reach each other privately, so the database needs no public endpoint.
A free plan and a 30-day trial for evaluation.

Usage-based billing on top of the base fee is hard to forecast for a memory-hungry stack.
The Pro fee is per workspace, which adds up for small teams.

Render

Best for: A conventional Rails production setup with the least ceremony.
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.

Release commands are first-class, so db:migrate runs once per deploy in the right place.
Managed Postgres, Redis, background workers and cron jobs are all available in one account.
A real free tier for evaluating, with straightforward fixed pricing afterwards.

Free services spin down after 15 minutes, and a Rails cold start is slow enough to be noticed.
The 512 MB Starter tier fits a single modest Puma worker; a real app outgrows it quickly.

Granite

Best for: Running the web app, the job runner and the database as one project without operating any of the infrastructure.
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.

Managed Postgres and Valkey sit beside the app over internal DNS — Postgres for the app and Solid Queue, Valkey if you prefer Sidekiq.
S3-compatible storage with a CDN is included, which is where Active Storage attachments belong.
Web, worker and scheduler are three resources built from one image with different commands, so they share code, secrets and deploys.
Databases have no public endpoint at all, and workspace seats are unlimited on every plan.

No free tier — the cheapest way in is $9/month.
The Hobby plan caps at 1 GiB per service, and Puma with several workers wants more, so Rails pushes you to Advanced sooner than a lighter stack would.
Fewer regions than the hyperscalers, and no multi-region routing yet.

Koyeb

Best for: An internal or low-traffic Rails app where paying nothing while idle matters.
Pricing: The Pro plan is $29/month; Scale is $299/month. Serverless Postgres has a small free allowance.

Managed Postgres available without leaving the platform.
Edge locations included rather than sold separately.

Scale-to-zero suits Rails badly: booting the app takes seconds and a real user waits through it.
The highest entry price of the managed options here.

Google Cloud Run

Best for: Stateless Rails services with bursty traffic, for teams already invested in 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 image, so the generated Rails Dockerfile applies unchanged.

No persistent disk, so Active Storage must use Cloud Storage from the outset.
Cold starts are seconds; setting min-instances to avoid them removes the saving that justified it.
Migrations need somewhere to run that is not a request handler, which means a separate job.

What a Rails app actually needs from a host

The requirements that matter for Rails are different from the ones every generic hosting listicle repeats.

Rails-specific criteria

Rails is opinionated about deployment, which is helpful: it means there is a short list of things a platform either supports properly or does not.

A real release phase: db:migrate must run once per deploy, after the image is built and before the new version takes traffic. Putting it in the container start command means every replica races to migrate the same schema simultaneously. Look for a release command or pre-deploy hook and refuse to improvise around its absence.
RAILS_MASTER_KEY: Encrypted credentials are the Rails way to carry secrets, and the master key is the one secret that cannot live in the repository. It has to arrive as an environment variable, ideally from encrypted storage rather than a plaintext settings field.
A process for jobs: Rails 8 defaults to Solid Queue, which runs on your existing database and removes the need for Redis; Sidekiq remains the popular alternative and does need it. Either way, jobs run in a separate long-lived process, built from the same image as the web app so it can never drift out of sync.
Active Storage needs a bucket: Attachments written to local disk vanish on deploy and are invisible to a second instance. Configure the S3 service against object storage before you accept the first upload, not after the first support ticket.
Asset precompilation at build: assets:precompile belongs in the image build, not at boot. It needs the same environment as production, which occasionally means the master key must be available during the build too — a detail platforms handle with varying grace.
Memory per Puma worker: Each Puma worker is a full copy of the application; threads within it are cheap, processes are not. Memory therefore tracks worker count rather than request volume, so size the plan by workers and verify against real usage rather than provisioning optimistically.

$ docker images rails-app
REPOSITORY   TAG      SIZE
rails-app    naive    1.9GB
rails-app    slim     507MB

The same Rails app built two ways: once on the full ruby image with the toolchain left in place, once multi-stage with gems built separately and copied onto a slim base. Just under four times smaller. Note where it stops — 507 MB is more than Django's slim build and far more than a compiled binary, because the interpreter, the gems and their native extensions all have to ship. That floor is worth knowing before you compare per-gigabyte prices.

So which should you pick?

You enjoy owning the machine and want the lowest bill. Kamal on a VPS. It is the setup Rails itself is designed around, and it is hard to beat on price. Budget an evening a month, and test your Postgres restore before you need it.

A conventional production app, least ceremony. Render. Release commands, managed Postgres and workers are all there and behave the way the Rails guides assume.

Fastest path to a running stack. Railway, whose templates assemble Rails, Postgres and Redis for you.

Web, jobs, database and attachments as one project. This is where we would argue for Granite. Postgres and Valkey run beside the app with no public endpoint, S3-compatible storage with a CDN gives Active Storage a home, and web, worker and scheduler are three resources from one image that deploy together. From $9/month, though a real Puma worker set will want the Advanced plan.

Running services in other languages beside it? The Go and Django comparisons cover the same platforms with different conclusions, and the app platform page covers workers and cron jobs in detail.

See Granite pricing

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.

Laravel hosting

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

Rails hosting — 6 options compared