Rails VPS Hosting

Ruby on Rails VPS hosting runs your app on one server with a disk that keeps data between deploys. Rails 8 launched as "No PaaS Required", and its defaults are built for that setup. On GreenGeeks VPS, the server runs AlmaLinux 9 with cPanel. You install Ruby 3.3, run the app under Puma, and let Apache pass requests to it. Rails 8 keeps jobs, caching and WebSockets in your database, so there's no Redis to run. GreenGeeks' managed team looks after the OS and the server, and you look after the app, its gems and its deploys.

One Rails 8 app on SQLite fits the 4 GB plan. Its 4 vCPU run 2 to 4 Puma workers, with jobs running inside Puma. Rails defaults to 3 threads per worker and suggests one worker per core. A typical worker uses about 400 to 600 MB, and some heavy apps see 1.8 GB per worker. Move to 8 GB with 6 vCPU when you add MariaDB or give jobs their own process. The 16 GB plan adds memory for heavier workers, not more cores. An app that needs more than 6 workers needs a second server.

No. Kamal installs Docker over SSH and runs each release in a container, and GreenGeeks VPS doesn't support Docker. Rails runs fine without it. Install Ruby 3.3 from AlmaLinux's own packages with dnf, run Puma under systemd, and let Apache send your domain's traffic to it. For each release, run git pull, bundle install, db:migrate and assets:precompile, then restart Puma. Capistrano can run those steps from your own computer. The Dockerfile and config/deploy.yml that Rails 8 generates can stay in the repo, unused.

Start with the four SQLite files in storage/. Copying a live database file with cp can leave you with a corrupt copy, so back them up with VACUUM INTO or the SQLite backup API, run as a recurring job in config/recurring.yml. For MariaDB, run mysqldump on a schedule instead. GreenGeeks doesn't back up VPS servers, so turn on cPanel's daily backups and send them to Amazon S3. Keep the app inside a cPanel account's home folder so those backups include it. Keep config/master.key in a password manager, since your encrypted credentials can't be read without it.

Yes, as long as the server keeps its disk between deploys, which a VPS does. Rails 8 made SQLite production-ready with WAL and IMMEDIATE mode on by default. A new app keeps four SQLite files in storage/, one for the main data and one each for the queue, the cache and Action Cable. On GreenGeeks VPS that folder is on the SSD, and each release leaves it alone. 37signals runs thousands of Campfire and Writebook installs on SQLite. It fits an app that runs on one server. Heroku can't run it, because a dyno's disk is wiped on restart.

Rails 8.0 and 8.1 need Ruby 3.2 or newer. The latest release, Rails 8.1.4, came out September 24, 2026. On AlmaLinux 9, you install Ruby 3.3 from the AppStream module with dnf, and YJIT turns on by itself. Gems with native code need gcc, make and ruby-devel, and root access lets you install them. For the database, SQLite works on GreenGeeks VPS, and so does MariaDB 11.4 through the mysql2 or trilogy adapter. PostgreSQL there is only version 9.6, which reached end of life in 2021, so MariaDB or SQLite is the better fit.

A Rails app on GreenGeeks VPS costs $69.95 a month on the 4 GB plan with 4 vCPU, $129.95 on 8 GB with 6 vCPU, or $179.95 on 16 GB. Puma, Solid Queue and MariaDB all share that one server, so one bill covers the web app, the background jobs and the database. One app on SQLite runs well on 4 GB. An app with MariaDB and a separate jobs process fits 8 GB, and heavy workers or a staging copy fit 16 GB. Beyond the plan, budget for off-site storage for your backups.

Plan the database move first. PostgreSQL on GreenGeeks VPS is version 9.6, so most apps switch to MariaDB 11.4 or SQLite. Change the adapter in config/database.yml, run db:prepare to build the schema, then copy your data over and test the app on the new database. Put your Heroku config vars into the Puma service file, along with RAILS_MASTER_KEY. When the app works on the new server, point your domain's A record at the dedicated IP. Keep the Heroku app running until the DNS change has reached everyone.

You look after Ruby, Rails, your gems and every deploy, and GreenGeeks' managed team keeps AlmaLinux and the server patched. Its help covers the server and cPanel, not the app. The most common Rails problems in the first month are a wrong thread count, assets that didn't precompile, and web and job processes sharing one database connection pool. WEB_CONCURRENCY=auto can also misread the CPU count on a virtual server, so set the worker count yourself. After each deploy, check the Puma service's logs with journalctl to catch a failed start early.

For the same memory, GreenGeeks costs less than Heroku. As of October 2026, Heroku's Performance-M dyno costs $250 a month for 2.5 GB, and a background worker needs a second dyno on top of that. GreenGeeks' 4 GB plan is $69.95 with 4 vCPU. Fly.io is cheaper at small sizes, at $33 for a 2 GB performance-1x machine, but its managed Postgres adds $38 a month on the Basic plan. Heroku's Essential Postgres plans run $5 to $20. On GreenGeeks, MariaDB runs on the same server at no extra charge, and the managed team handles OS patches.