Ruby on Rails Hosting
Heroku made Rails hosting accessible for a decade - and then removed its free tier. Production-ready Rails on Heroku now costs $50 or more per month once you add PostgreSQL and Redis. A VPS gives you the same environment at a flat monthly rate: Puma as your application server, Nginx handling SSL and static assets, PostgreSQL and Redis running alongside your application, and your choice of Capistrano or Kamal for deployments.
How Rails runs on a VPS
The production Rails stack has three layers: Puma handles application requests, Nginx sits in front of Puma to manage SSL and serve static files, and systemd keeps both processes running and restarts them if they exit. Ruby and your application's gems install into an environment managed by rbenv, keeping different projects and Ruby versions cleanly separated.
Puma - the Rails application server
Puma is the default application server since Rails 5. Unlike single-threaded servers, Puma is multi-process and multi-threaded: it spawns multiple worker processes (WEB_CONCURRENCY), and each worker handles multiple concurrent requests in separate threads (RAILS_MAX_THREADS, defaulting to 5). A VPS-2 running two Puma workers with five threads each handles up to ten concurrent requests. Configure workers and threads in config/puma.rb or via environment variables. Puma communicates with Nginx via a Unix socket or TCP port, and systemd manages the Puma process.
rbenv - Ruby version management
rbenv installs into your home directory and manages multiple Ruby versions side by side. Install the Ruby version your application's .ruby-version file specifies, and rbenv uses it automatically whenever you're in that project directory. RVM is the alternative - it provides similar functionality with a different management model. Either works on a Bitfoo VPS; rbenv is the more commonly used choice for new setups.
Bundler - dependency management
bundle install reads your Gemfile.lock and installs the exact gem versions your application requires into the project's bundle. Running with --without development test skips gems that are not needed in production. Bundler is installed alongside Ruby; no separate installation is required.
Asset precompilation
In production, Rails does not serve assets directly - it precompiles them into public/assets/ for Nginx to serve statically. Run RAILS_ENV=production bundle exec rails assets:precompile as part of your deployment workflow, before restarting Puma. For Rails 7+ applications using importmaps, no Node.js is required for compilation. For applications using esbuild, Vite, or webpack, Node.js must be installed on the server or in your CI/CD pipeline.
Nginx - reverse proxy and static file serving
Nginx listens on ports 80 and 443, handles SSL termination via Certbot and Let's Encrypt, and proxies application requests to Puma. The public/ directory and precompiled public/assets/ are served directly by Nginx without involving Ruby - configure a root directive pointing to your application's public/ directory and let Nginx try files there before falling back to Puma. Action Cable WebSocket connections pass through Nginx with Upgrade and Connection headers configured in the proxy block.
Encrypted credentials - the master.key
Rails 7 stores application secrets in config/credentials.yml.enc, encrypted with a key in config/master.key. The master.key file must exist on your server for Rails to start, and it must not be committed to your git repository - add it to .gitignore. If you lose the master.key, the encrypted credentials file cannot be recovered. Store the key securely: copy it to the server once during initial setup, or set the RAILS_MASTER_KEY environment variable instead of using a file.
Deploying Rails - Capistrano or Kamal
Rails has two mainstream deployment approaches with meaningfully different architectures. The right choice depends primarily on your Rails version and whether you prefer file-based or container-based deployments.
Capistrano - file-based deployment
Capistrano has been the standard Rails deployment tool for many years. It connects to your server over SSH,
pulls new code from your git repository, installs gems, precompiles assets, runs rails db:migrate
against your production database, and restarts Puma - all in a structured release directory that maintains a
history of recent deployments and supports instant rollback. Configuration lives in Capfile,
config/deploy.rb, and environment-specific files in config/deploy/. It requires no
Docker and works with all Rails versions. Capistrano's plugin library is extensive, with integrations for
rbenv, Bundler, and Puma already available as gems. The deployment command is a single
cap production deploy.
Kamal - Docker-based deployment (Rails 8 default)
Kamal is the deployment tool developed by 37signals and shipped with Rails 8 as the default. It builds your
Rails application as a Docker container image on your development machine (or in CI/CD), pushes it to a
container registry, and pulls it to the server. Docker must be installed on the server, so if you're
deploying Rails with Kamal see the Docker hosting page
for setup guidance. Kamal handles zero-downtime deployments by default - it starts the new container before
stopping the old one - and includes built-in rollback, health checks, and support for multi-server
deployments. Configuration is in config/deploy.yml. If you're starting a new Rails 8
application, Kamal is the default and the simpler choice for greenfield deployments. For applications already
using Capistrano, there's no need to migrate.
Plans
Rails applications vary in resource usage depending on traffic, Puma worker count, and what's running alongside them. All plans run on KVM with dedicated AMD Ryzen 9 9900X resources. Puma's capacity formula is workers * threads, with Rails defaulting to 5 threads per worker.
| VPS-1 Low-traffic applications, single Puma worker, or development and staging environments | VPS-2 Most production Rails apps - 2 Puma workers, PostgreSQL, Redis, and Sidekiq with comfortable headroom | VPS-4 Higher-traffic applications, 4 Puma workers, or larger Sidekiq worker pools | VPS-6 High-traffic production workloads or multiple Rails applications on one server | |
|---|---|---|---|---|
| vCPU | 1 | 2 | 4 | 6 |
| RAM | 1GB DDR5 | 2GB DDR5 | 4GB DDR5 | 8GB DDR5 |
| Storage | 25GB NVMe | 50GB NVMe | 100GB NVMe | 200GB NVMe |
| Bandwidth | 1TB | 2TB | 4TB | 6TB |
| IPv4 | 1 | 1 | 1 | 1 |
| Price | [price] | [price] | [price] | [price] |
| Deploy your VPS. | Deploy your VPS. | Deploy your VPS. | Deploy your VPS. |
These are renewal prices. What you pay today is what you pay next year.
All VPS plans are unmanaged. Bitfoo handles the hardware and network; your Rails environment, application server configuration, deployments, and maintenance are your responsibility.
If your server exceeds its monthly bandwidth allocation, throughput is throttled for the remainder of the billing cycle - no additional charges.
Puma's recommended worker count matches your vCPU count. With Rails' default of 5 threads per worker, that's 5 concurrent requests on VPS-1, 10 on VPS-2, 20 on VPS-4, and 30 on VPS-6. Factor in RAM for PostgreSQL, Redis, and any Sidekiq workers running alongside Puma when sizing your plan.
What every VPS plan includes
Relevant features for Rails, from the VPS hosting page:
Full root access and SSH from first boot - required for rbenv, Bundler, Puma, Nginx, PostgreSQL, Redis, and any deployment tooling you use
KVM virtualization - your own kernel; Puma's multi-process worker model, systemd service management, and Kamal's Docker runtime all operate without host-imposed restrictions
AMD Ryzen 9 9900X - strong single-core performance for Ruby's request processing; Puma's multi-threaded model benefits from high single-thread throughput
NVMe SSD storage - fast I/O for ActiveRecord queries, PostgreSQL operations, and asset file access
10Gbps network ports on all plans
IPv6 included on every plan
Self-service control panel - OS reinstall, power control, SSH key management, resource monitoring, and browser-based emergency console
99.9% uptime SLA - measured monthly, service credit issued for any shortfall
Automated provisioning - server ready within minutes of payment
5 datacenter locations at order time: US East, US West, UK, EU, Asia-Pacific
Who uses this
Ruby on Rails is a mature framework with a loyal developer base - it powers content platforms, SaaS applications, marketplaces, and internal tools, often chosen specifically for its developer productivity and convention-over-configuration approach.
Developers · Startups · SaaS companies · Agencies
Common questions
Can I run Ruby on Rails on Bitfoo shared hosting?
No. Rails requires Puma or another application server running as a persistent process, asset precompilation, and direct database access - none of which shared hosting can provide. Rails does not run on shared hosting in any meaningful production capacity. A VPS is the correct environment.
How do I manage Ruby versions on a VPS?
Install rbenv from its official repository at github.com/rbenv/rbenv. It installs into your home directory and lets you install any Ruby version with rbenv install 3.3.0 (or whichever version your application requires). Create a .ruby-version file in your project root - rbenv uses it automatically when you're in that directory. The ruby-build plugin handles the actual Ruby compilation. RVM is the alternative tool with similar functionality; use whichever you're more familiar with. Both work without issue on Ubuntu or Debian.
How do I handle Rails credentials and the master.key securely?
Rails stores application secrets in config/credentials.yml.enc, encrypted with a key that lives in config/master.key. The master.key must be on your server but must never be in your git repository - it should already be in .gitignore by default. The two standard approaches: copy the file to config/master.key on your server during initial setup (via scp or a secure paste over SSH), or set the RAILS_MASTER_KEY environment variable in your systemd service file or Capistrano configuration instead of using a file. If you're using Kamal, store it as a secret in your Kamal configuration. If you lose the master.key and have no backup, the contents of credentials.yml.enc cannot be recovered - keep a secure copy somewhere outside your server.
How does Action Cable work in a self-hosted Rails application?
Action Cable is built into Rails and runs inside your Puma process - no separate application server is needed. It handles WebSocket connections alongside your standard HTTP requests. For production, configure the Redis adapter in config/cable.yml (Action Cable uses Redis to broadcast messages between Puma workers). Install Redis on your VPS, add the redis gem to your Gemfile, and update config/cable.yml to point to your Redis instance. Nginx needs two additional proxy headers to pass WebSocket upgrade requests through to Puma: proxy_set_header Upgrade $http_upgrade and proxy_set_header Connection "upgrade". With those in place, Action Cable connections work without further configuration.
Should I use Sidekiq or Solid Queue for background jobs?
It depends on your Rails version and preference. Sidekiq is the dominant background job library for Rails - it uses Redis as its queue backend, is fast and battle-tested, and has a rich plugin library for job retries, scheduling, and monitoring via Sidekiq Web. Run it as a separate systemd service alongside Puma. Solid Queue is Rails 8's new default, developed by 37signals - it uses your database as the queue backend, which means no Redis dependency for job processing. It's simpler to set up for straightforward use cases and integrates with Rails' new Mission Control dashboard. If you're starting a new Rails 8 application and want to minimise dependencies, Solid Queue is a reasonable default. If you need fine-grained job control, scheduling, or high job throughput, Sidekiq remains the more feature-complete option.
Do I need Node.js to run a Rails application?
It depends on your asset pipeline configuration. Rails 7+ introduced importmaps as the default JavaScript approach - if your application uses importmaps, no Node.js is required for asset compilation. However, if your application uses a JavaScript bundler (esbuild, Vite, or webpack via jsbundling-rails or cssbundling-rails), Node.js must be available during rails assets:precompile. In that case, install Node.js via NVM alongside your Ruby environment. Rails 8 continues the same pattern - check whether your application's Gemfile includes jsbundling-rails or cssbundling-rails to determine whether Node.js is needed.
Which plan should I choose for my Rails application?
Size based on Puma worker count plus your supporting services. VPS-1 suits low-traffic applications or staging environments - one Puma worker handles up to 5 concurrent requests with default thread settings. VPS-2 is the recommended starting point for most production Rails applications: two Puma workers handle 10 concurrent requests, with enough RAM left for PostgreSQL, Redis, and a Sidekiq process running simultaneously. VPS-4 suits higher-traffic applications or deployments with a larger Sidekiq worker pool. VPS-6 suits high-traffic production workloads or servers running multiple Rails applications. When in doubt, start on VPS-2 - you can upgrade without migrating your data, and it handles the baseline Rails stack with headroom.