Back to Blog
Guide10 min read2026-07-05

Best Ruby on Rails Hosting in 2026

Rails in 2026 is leaner than ever with Solid Queue, Kamal, and Hotwire. Here's how to host it well, what each platform gets right, and where the trade-offs land.

Ajay Kumar
Ajay Kumar
Founder & DevOps, PandaStack

The modern Rails deployment landscape

Rails has shifted in an interesting direction. The official stack now leans toward Kamal for deploying Docker containers to your own servers, Solid Queue / Solid Cache / Solid Cable to reduce the Redis dependency, and Hotwire for the front end. That changes the hosting conversation: you can run a very capable Rails app with just a container and a Postgres database now.

That said, a production Rails app still typically needs:

  • A web process (Puma).
  • A job worker (Solid Queue, Sidekiq, or GoodJob).
  • Migrations on deploy (rails db:migrate).
  • Asset precompilation (assets:precompile) at build time.
  • A database (Postgres is the default) and often Redis if you use Sidekiq or Action Cable the old way.

The platforms

Heroku

The platform Rails grew up on. Still a genuinely good, batteries-included experience: git push heroku main, a Procfile for your processes, and add-ons for Postgres and Redis. It's not the cheapest, but the developer experience and ecosystem maturity are real. If you want zero infrastructure thinking, Heroku still delivers.

Render and Railway

Both are strong modern Heroku-style options. You declare web + worker processes, attach a managed Postgres, and deploy on push. Render's render.yaml blueprint and Railway's service model both handle multi-process Rails cleanly. Good defaults, fair pricing — check current plans.

Fly.io + Kamal

If you've adopted the official Kamal path, you can deploy to your own VMs anywhere, or use Fly to run containers near users. This is the most control and the most DIY. Great when latency or cost-at-scale matters and you're comfortable owning more.

PandaStack

My platform, so judge accordingly. PandaStack runs Rails as a container app. With a standard Dockerfile it deploys on git push:

FROM ruby:3.3-slim
RUN apt-get update && apt-get install -y build-essential libpq-dev nodejs
WORKDIR /app
COPY Gemfile Gemfile.lock ./
RUN bundle install
COPY . .
RUN bundle exec rails assets:precompile
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

Attach a managed PostgreSQL (14.x/16.x) and DATABASE_URL is injected automatically — Rails reads it natively, so database.yml needs nothing special. Run a second service as your Solid Queue / Sidekiq worker, add managed Redis if you need it, and use cronjobs for scheduled tasks (rails some:rake_task). Live logs, automatic SSL on custom domains, and rollbacks are built in.

Honest limits: no Rails-specific buildpack magic beyond standard buildpacks/Docker — you bring the Dockerfile. It's a newer platform, and free-tier apps cold-start on preemptible nodes, which can interrupt a long-running Action Cable connection on the free plan.

Getting the deploy right

# Build time
bundle install
rails assets:precompile RAILS_ENV=production

# Release/deploy time (run once across replicas)
rails db:migrate

# Runtime processes
bundle exec puma -C config/puma.rb        # web
bundle exec rake solid_queue:start         # worker (or sidekiq)

The classic footgun is running db:migrate in every container's entrypoint. With multiple replicas that races. Make it a release/deploy step or a one-off job.

Puma tuning

Puma uses workers (processes) and threads. A reasonable production starting point:

# config/puma.rb
workers ENV.fetch("WEB_CONCURRENCY", 2)
threads_count = ENV.fetch("RAILS_MAX_THREADS", 5)
threads threads_count, threads_count
preload_app!

Match your DB connection pool (RAILS_MAX_THREADS) to threads per worker, and size your database connection limit for workers * threads * replicas. Blowing past the DB connection cap is the most common Rails-at-scale outage I see.

References

  • [Rails deployment guide](https://guides.rubyonrails.org/configuring.html)
  • [Kamal deployment](https://kamal-deploy.org/)
  • [Puma documentation](https://github.com/puma/puma)
  • [Solid Queue](https://github.com/rails/solid_queue)
  • [Heroku Ruby support](https://devcenter.heroku.com/articles/ruby-support)

---

Want Rails + Postgres wired together automatically with a worker and cron alongside? PandaStack's free tier covers it. Deploy your app at [dashboard.pandastack.io](https://dashboard.pandastack.io).

Ready to deploy?

Start free on PandaStack.

Start free on PandaStack

More in Guide

Browse all Guide articles →

See also