Ruby on Rails VPS Deployment Guide: Puma, Nginx, PostgreSQL and systemd

A production Rails deployment on a VPS runs the app under Puma, managed by systemd, behind Nginx, with PostgreSQL alongside and background jobs in their own process. The Rails guides cover configuration and security. Puma's deployment notes cover workers and threads. This guide ties them together on a KVM VPS.

Prerequisites

• A KVM VPS with root access. VPS 8 (4 vCPU, 8 GB, ₹1,438) is a sensible production start for an app and its database.
• Ruby installed with a version manager, and your app's Ruby version pinned.
• PostgreSQL installed and a database user created for the app.

Step 1: production configuration

• Set RAILS_ENV=production.
• Keep secrets in Rails encrypted credentials and provide the master key through an environment variable, not the repository.
• Force SSL in production so cookies are only sent over HTTPS, as the Rails security guide recommends.

Step 2: Puma workers and threads

Puma combines processes (workers) and threads. Puma's deployment documentation suggests starting with one worker per CPU core and a small number of threads per worker, then tuning from measurements.

# config/puma.rb
workers Integer(ENV.fetch("WEB_CONCURRENCY", 4))
threads_count = Integer(ENV.fetch("RAILS_MAX_THREADS", 5))
threads threads_count, threads_count
preload_app!
bind "unix:///srv/app/tmp/puma.sock"

Match the database connection pool to the thread count, or requests will wait for connections.

Step 3: systemd

[Service]
User=app
WorkingDirectory=/srv/app
Environment=RAILS_ENV=production
EnvironmentFile=/srv/app/.env
ExecStart=/home/app/.rbenv/shims/bundle exec puma -C config/puma.rb
Restart=on-failure

Step 4: Nginx

Proxy to the Puma socket, serve precompiled assets from public/assets directly with long cache headers, and terminate TLS in Nginx. The Rails asset pipeline guide explains precompilation.

Step 5: deploy sequence

1. bundle install --deployment --without development test
2. bin/rails assets:precompile
3. bin/rails db:migrate
4. Restart Puma through systemd, or use a phased restart for zero downtime.

Step 6: background jobs

Run your Active Job backend as its own systemd service so a slow job never blocks web requests, and restart it on each deploy.

Sizing

Monthly INR, excluding GST. All ten sizes, from 1 GB (₹149) to 128 GB (₹19,099), are on the VPSWala cloud VPS plans page. Every plan is KVM with RAID NVMe storage and full root access.

Ruby request handling benefits from fast single cores. For CPU-heavy apps, compare the Ryzen 9 9950X VPS plans.

VPSWala plans are unmanaged unless you agree otherwise in writing: the host platform, network and provisioning are VPSWala's job, and everything inside the VM is yours. Per the terms of service, off-server backups, control-panel licences, Windows licensing, managed administration and extra IPv4 addresses are quoted separately, and any availability commitment applies only where it is written into your quotation or agreement.

Verify the deployment

1. Load the app over HTTPS and confirm HTTP redirects to HTTPS.
2. Check that asset URLs return long cache headers from Nginx.
3. Kill a Puma worker and confirm the master replaces it.
4. Reboot the VPS and confirm Puma and the job runner return on their own.
5. Run a database backup and restore it to a scratch database.

Security checklist

• Keep config/master.key out of the repository.
• Run the app as a non-root user.
• Keep Ruby, gems and the operating system patched, and run a dependency audit regularly.
• Firewall everything except SSH, HTTP and HTTPS.

Logs and monitoring

Log to standard output and let systemd's journal collect it, or write to log/production.log with daily rotation. Track response times, error rates and Puma's backlog. A growing backlog with idle CPU usually means the database pool is too small or a slow external call is holding threads. Add an external uptime check against a lightweight health route that also touches the database.

Record the Ruby, Rails and PostgreSQL versions in the repository so the next deploy, or a rebuild on a larger plan, repeats this setup exactly.

Frequently asked questions

How much memory does a Rails app need?

Measure one Puma worker after warm-up, multiply by the number of workers, and add PostgreSQL, the job runner and the operating system.

Should PostgreSQL run on the same VPS?

For small and medium apps, yes. Move it to its own VPS when it needs its own memory or you want to scale web servers separately.

Capistrano or containers?

Both are fine. Choose one and document it so every deploy is the same.

Sources

• Ruby on Rails Guides: Configuring Rails Applications
• Ruby on Rails Guides: Securing Rails Applications
• Puma documentation: Deployment engineering for Puma
• Ruby on Rails Guides: The Asset Pipeline