Rails has matured — and hosting expectations with it. The era of "FTP and MySQL" is over. Today, a clean Rails deploy needs versioned Ruby, compiled assets, PostgreSQL, async jobs and secrets in environment variables — a scope most entry-level PHP hosting simply does not offer.
A team signing generic "PHP-compatible" shared hosting often discovers in production that Puma cannot stay alive, PostgreSQL is unavailable, and nobody knows how to run an Active Job worker. The framework is not at fault: the host was not prepared for Rails, only for generic PHP.
Reasonable expectations in 2026
| Rails need | Host expectation | Typical PHP shared |
|---|---|---|
| Ruby 3.2+ | Selectable version | No |
| PostgreSQL | Yes | MySQL only, often |
| Persistent web process | Puma behind nginx | No |
| Active Job / Solid Queue | Worker process | No |
| Redis (optional) | Recommended | Rare |
| Asset pipeline | Build on deploy | N/A |
| SSH + automated deploy | Yes | Very limited |
Expecting level-1 Rails support on a four-euro unmanaged VPS means confusing infrastructure price and application service. Rails needs a long-lived environment — not a PHP page executed on demand.
An honest host quickly admits what it does not do: no Ruby, no worker, no PostgreSQL.
Three Rails hosting paths
Rails-friendly platform. Git-push deploy, DB and Redis add-ons, horizontal scaling. Higher cost, lower operational load. Fits product teams without a dedicated sysadmin.
VPS + Hatchbox, Capistrano or Kamal. Full control, low infra cost, you or a contractor administer. Kamal (Rails 8) targets containerised deploy on VPS — a strong 2026 trend.
Managed cloud + containers. Kubernetes or equivalent if container culture already exists — rare for a first Rails app.
Production deploy checklist
Before launch, verify RAILS_ENV=production is set and credentials are encrypted or injected by the environment. The CI pipeline must run assets:precompile and tests. Database migrations (db:migrate) come with a backup. Puma runs behind nginx or a load balancer. A Solid Queue or Sidekiq worker is supervised (systemd or equivalent). The /up healthcheck (Rails 7.1+) responds correctly. Logs are centralised — not only in local log/production.log.
Solid Queue, Cable and Cache (Rails 8)
Rails 8 pushes database-backed adapters. That changes host expectations: PostgreSQL must handle job writes, a worker process remains mandatory, and job latency must be monitored. Redis becomes optional for some cases but stays useful at scale or with legacy Sidekiq.
The climax: Rails wants an honest host about limits
Compare offers via the directory and long-running deploy culture in Node.js first app — principles overlap.
Decide and move forward without blind spots
First choose between a managed platform and VPS with Kamal based on team operational skill. Require managed PostgreSQL from production — not a shared dev database. Plan a worker for tasks as soon as you send emails or run async imports. Set up CI with asset precompilation and automated tests. Test a database restore before launch. Compare documented hosts via the compare tool and guides.
Frequently asked questions
Can you host Rails on shared hosting?
Very rarely — without selectable Ruby, persistent processes and suitable PostgreSQL, Rails does not run properly. Rails platform or VPS remains the norm.
Do you still need Redis with Rails 8?
Less mandatory thanks to Solid Cache/Queue/Cable; Redis stays useful for performance and existing Sidekiq setups.
Does Kamal replace PaaS?
Kamal simplifies VPS deploy; PaaS removes more operational load. Choice depends on the team, not buzz.
What should you ask host support?
Ruby 3.2+, PostgreSQL, SSH access, backups, and clarity on the Rails support scope actually covered.
Rails in 2026 is not looking for the trendiest host — it is looking for one that admits whether it can keep Puma running at midnight.