Ruby on Rails Hosting on Your Own VPS
Rails behind Puma with Sidekiq and PostgreSQL, on a server with enough memory to matter.
Size a server for Ruby on Rails
Every stop is a real configuration you can deploy. Priced per month and billed monthly, exclusive of 18% GST.
What Ruby on Rails is
Ruby on Rails runs as a long-running application server, typically Puma, with NGINX in front for TLS and static assets and PostgreSQL behind. The pattern resembles Django's, but the resource profile does not.
Rails is memory-hungry, and this is the single most common way Rails hosting is got wrong. Each Puma worker is a full copy of the application in memory — commonly 200 to 400 MB for a real application, more with many gems. Four workers is well over a gigabyte before the database or Redis has anything, and undersizing shows up as the OOM killer terminating workers under load rather than as a gradual slowdown.
Background jobs usually mean Sidekiq, which is another process holding another copy of the application. Budget for it explicitly rather than discovering it. Asset precompilation during deploy is also memory-hungry, and is a step that fails on small servers even when steady-state use would have fit.
“Rails is a web application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.”
Why run Ruby on Rails on a VPS
Memory sized for Puma workers rather than for a PHP script — the actual Rails constraint.
Sidekiq under a supervisor, restarted on failure and on deploy.
Root access for native gem extensions that need system libraries.
PostgreSQL locally, which is the Rails default for good reasons.
Ruby on Rails features
Puma behind NGINX with TLS
PostgreSQL with direct access
Sidekiq with Redis for background jobs
Asset pipeline or jsbundling, precompiled at deploy
rbenv or rvm for Ruby version management
Credentials and environment handled outside the repository
Ruby on Rails hosting requirements
The recommended starting point for Ruby on Rails, not a hard floor — size it on the sliders.
| Memory | 8 GB. Each Puma worker holds a full copy of the app — this is not the place to economise |
|---|---|
| CPU | 4 vCPU; worker count tracks cores |
| Storage | 40 GB, more with significant uploads |
| Operating system | Ubuntu 24.04 LTS or Debian 13 |
| Installs on | Ubuntu 24.04 LTS, Debian 13 (Trixie) |
| Ready in | About 8 minutes |
| Smallest server | 2 vCPU · 4 GB memory · 20 GB disk |
How deployment works
Rails is deployed with Puma behind NGINX, PostgreSQL locally, and Sidekiq under a supervisor if the application uses it. Ruby is managed with rbenv so the version is pinned. Size memory before deploying rather than after: asset precompilation is memory-hungry and is where undersized servers fail first, before the application has served a single request.
What people run it for
Rails applications
Standard deployments with migrations, assets and background jobs.
APIs
Rails in API mode with worker counts you control.
Background-heavy work
Sidekiq queues for mail, imports and integrations.
Moving off a PaaS
The same stack at server prices rather than per-dyno pricing.
Ruby on Rails hosting questions
Related applications
Django Hosting Django behind Gunicorn with PostgreSQL and Celery, on a server built for long-running processes. 
Laravel Hosting Laravel with working queues, a real scheduler and Redis — the parts shared hosting cannot provide. 
Redis Hosting In-memory cache, sessions and queues, priced as memory rather than per gigabyte. 
GitLab Hosting Repositories, CI/CD and a container registry on your own server. 
LAMP Hosting Linux, Apache, MySQL and PHP, with .htaccess support and root over all of it. Deploy Ruby on Rails on your own server
Root access, your choice of size, and no container between you and the application.