Offshore Ruby on Rails VPS Hosting

Ruby on Rails production deployment on a Debian 12 VPS uses Puma as the application server, Nginx as the reverse proxy, PostgreSQL as the database, Sidekiq with Redis for background jobs, and rbenv or rvm for Ruby version management. Install rbenv from the rbenv GitHub repository for clean Ruby version management that does not require root - create a deploy user, install rbenv for that user, and install the target Ruby version (typically 3.3.x for Rails 7.x applications).

Puma configuration: set workers to the CPU count and threads to 5 per worker for the default configuration. For a 2 vCPU VPS, this means 2 Puma workers x 5 threads = 10 concurrent request handlers. Puma workers use copy-on-write from the master process, so RAM usage scales sublinearly with worker count after the first worker. Bind Puma to a Unix socket (bind "unix:///tmp/puma.sock") and reference the socket path in Nginx's proxy_pass directive. Create a systemd service for Puma to ensure it starts on boot and restarts on failure.

PostgreSQL is the preferred database for Rails applications - ActiveRecord's PostgreSQL adapter supports the full range of PostgreSQL features including JSONB, arrays, and full-text search that Rails applications frequently use. Install PostgreSQL 15 or 16, create a database role for your Rails application with LOGIN permission and CREATEDB for running rails db:create in development (revoke CREATEDB in production). Configure database.yml to use environment variables for credentials rather than hardcoded values.

Asset pipeline: compile assets with RAILS_ENV=production bundle exec rails assets:precompile before deployment. Precompiled assets go to public/assets with digest fingerprinting. Nginx serves these assets directly (bypassing Puma) via the root directive pointing to your Rails app's public directory and a try_files check that returns assets directly if they exist. This configuration is standard in Rails deployment guides and keeps Nginx doing what it does best (serving static files at high concurrency) while Puma handles dynamic Rails requests.

Sidekiq is the standard background job processor for Rails applications. It uses Redis for its job queue and runs as a separate process alongside Puma. On a VPS, run Sidekiq as a systemd service with a unit file that starts it after Redis and Puma. Sidekiq's concurrency is configurable - the default is 10 threads, which is appropriate for I/O-bound jobs (API calls, email sending, file uploads). For CPU-bound jobs (image processing, data transformation), reduce concurrency to match CPU count to avoid thread contention.

Sidekiq Pro is a commercial upgrade that adds retries per job, batches, and cron scheduling. For open-source projects, the sidekiq-scheduler gem adds cron-style scheduling to standard Sidekiq. Scheduled jobs on Sidekiq replace the need for cron entries that call rails runner - all scheduling is visible in the Sidekiq Web UI dashboard.

Redis configuration for Sidekiq: allocate at least 256 MB of RAM to Redis on the VPS. For applications with many queued jobs or large job payloads, increase this to 512 MB or 1 GB. Set maxmemory-policy to noeviction for Sidekiq's Redis instance - Sidekiq cannot function correctly if Redis evicts keys from the queue. This differs from the cache Redis configuration, which typically uses allkeys-lru. If you run both Sidekiq and cache use cases, run two Redis instances on different ports with different maxmemory-policy settings, or use Redis namespacing to separate Sidekiq data from cache data.

For offshore Rails applications running privacy tools or communication platforms, Sidekiq handles asynchronous sensitive operations: sending encrypted emails, processing uploaded documents, generating audit trails, and triggering notifications. The Sidekiq job queue stores job arguments in Redis - if job arguments contain sensitive user data, ensure Redis data at rest is protected. LUKS encryption on the VPS data volume where Redis writes its RDB snapshots ensures that Redis persistence data is encrypted on disk.

Ruby's memory management has improved significantly in recent versions (3.x garbage collector), but Rails applications still accumulate memory over time due to Ruby object allocation patterns. Understanding and managing memory is essential for stable Rails operation on a VPS where RAM is a fixed resource.

Puma's out-of-band garbage collection (puma-plugin-tmp_restart) restarts workers that exceed a memory threshold. Configure this with a memory limit appropriate for your application's normal footprint plus a 20-30% buffer. A Rails app that typically uses 400 MB per Puma worker should trigger a restart at 520 MB. Worker restart is graceful - Puma starts a replacement worker before killing the memory-heavy one, maintaining request handling capacity. This prevents gradual memory bloat from accumulating until the VPS OOM killer terminates Puma uncleanly.

Rails memory profiling tools: the memory_profiler gem identifies which libraries and code paths allocate the most objects. Run it in development against a production-representative workload to identify memory-heavy code paths. The allocation_stats gem provides similar analysis. Common memory hotspots in Rails applications: N+1 ActiveRecord queries that load many objects, eager loading joins that return more data than needed, and ActiveRecord callbacks that instantiate associated objects unnecessarily.

For applications that grow beyond what a single VPS can handle: the first scaling step for Rails is increasing the VPS tier to get more RAM and CPU. AnubizHost VPS goes up to 8 vCPU / 16 GB RAM, which handles substantial Rails traffic. Beyond that, horizontal scaling requires separating the database to a dedicated VPS, adding a second Rails application VPS, and putting a load balancer (Nginx or HAProxy) in front. Sticky sessions are not required for Rails if you use Redis for sessions (config.session_store :redis_session_store in an initializer) - any Rails instance can serve any request when sessions are shared via Redis.

Several Rails application categories particularly benefit from offshore VPS hosting. Understanding these use cases clarifies when the legal and technical architecture of offshore hosting adds meaningful value versus when a standard managed Rails host (Heroku, Render, Fly.io) is more appropriate.

Independent publishing platforms: Rails-based publishing tools (similar to Ghost or Medium) that host independent journalism, political commentary, or content in niches that US platforms are increasingly pressuring. An offshore Rails application gives publishers full control over their content and their platform with no deplatforming risk from US hosting decisions. Iceland's IMMI press freedom provisions provide specific legal protection for this use case.

Whistleblowing and source protection infrastructure: SecureDrop is built on Python, but custom secure document submission systems built on Rails are deployed by organizations that prefer Ruby's ecosystem. Offshore Rails hosting in Iceland provides the strongest legal protection for this infrastructure, with IMMI source protection law specifically covering this type of tool.

Cryptocurrency and DeFi application backends: Rails serves as the backend for many crypto wallet interfaces, exchange front-ends, and DeFi dashboards. Applications that interact with cryptocurrency networks need hosting outside US jurisdiction if they serve users in jurisdictions where crypto regulation conflicts with US enforcement posture. Offshore hosting means the application's user and transaction data is outside direct US subpoena reach.

Privacy communication tools: Rails powers many open-source encrypted communication platforms (encrypted file sharing, private messaging APIs, secure document collaboration). These benefit from offshore hosting both for jurisdiction reasons and for the absence of US cloud provider AUP enforcement that has historically targeted privacy tools. Running on AnubizHost offshore VPS keeps the Rails application, its database, and its Redis state entirely within Iceland or Romania's legal framework.