Ruby on Rails 8 Kamal 2 Multi-Server Clustering: Web, Solid Queue & PostgreSQL High Availability

Direct Answer: Production Ruby on Rails 8 Clustering with Kamal 2

Kamal 2 redefines zero-downtime multi-server deployments by routing traffic via Traefik while decoupling application workloads. By segmenting your infrastructure into dedicated web nodes, Solid Queue background workers, and managed PostgreSQL instances, you achieve true horizontal scalability without the complexity of traditional Kubernetes.

As enterprise engineering teams modernize their stacks, deploying monolithic Rails 8 applications across distributed cloud instances requires precise orchestration. At TechVinta, our expert engineers design fault-tolerant infrastructure, ensuring your multi-server topology remains robust under heavy production loads with a seamless 4-6 hour US timezone overlap for real-time collaboration.

The Kamal 2 Multi-Server Architecture Blueprint

In a production-grade Kamal 2 topology, separation of concerns is critical. Running web servers, background queue processors, and database operations on the same host introduces resource contention and cascading failures. Our target architecture distributes services cleanly across dedicated instances:

• Web Nodes (Primary & Secondary): Handle inbound HTTP traffic, execute stateless request-response cycles, and manage SSL termination through Traefik.
• Worker Nodes: Execute asynchronous jobs managed by Rails 8's native Solid Queue, isolated from web traffic spikes.
• Managed PostgreSQL: Runs on a high-availability cluster (such as AWS RDS or DigitalOcean Managed Databases) with automated failover and read replicas.

Step 1: Configuring deploy.yml for Multi-Role Separation

The core of Kamal 2 configuration lies in defining distinct roles within your config/deploy.yml file. This tells Kamal where to build, push, and run specific Docker containers.

# config/deploy.yml
service: techvinta-app
image: registry.digitalocean.com/techvinta/app

servers:
  web:
    - 192.168.1.10
    - 192.168.1.11
  worker:
    hosts:
      - 192.168.1.20
    cmd: bundle exec bin/jobs

proxy:
    ssl: true
    host: app.techvinta.com
    healthcheck:
      path: /up
      interval: 5
      timeout: 2

registry:
  username: techvinta
  password:
    - KAMAL_REGISTRY_PASSWORD

builder:
  arch: amd64
  remote:
    host: 192.168.1.50

env:
  secret:
    - RAILS_MASTER_KEY
    - DATABASE_URL
  clear:
    DB_POOL: 5
    SOLID_QUEUE_IN_PUMA: false

Step 2: Configuring Solid Queue for Clustered Workers

Rails 8 introduces Solid Queue as the default database-backed queue engine. To prevent race conditions and ensure optimal throughput across your dedicated worker nodes, configure config/solid_queue.yml to run multiple dispatchers and workers.

# config/solid_queue.yml
default: &default
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: [default, critical]
      threads: 5
      processes: 2
      polling_interval: 0.5
    - queues: [background, mailers]
      threads: 3
      processes: 1
      polling_interval: 2

development:
  <<: *default

production:
  <<: *default

Step 3: Database High Availability and Connection Pooling

When running a clustered Rails 8 app, your database connection pool must account for both web nodes and worker nodes. Configure your config/database.yml to use primary and replica connections safely while leveraging Solid Queue's dedicated connection requirements.

# config/database.yml
production:
  primary: &primary
    adapter: postgresql
    encoding: unicode
    pool: <%= ENV.fetch("DB_POOL") { 5 } %>
    url: <%= ENV.fetch("DATABASE_URL") %>
    connect_timeout: 2
    checkout_timeout: 5

  primary_replica:
    <<: *primary
    url: <%= ENV.fetch("DATABASE_READ_REPLICA_URL") { ENV.fetch("DATABASE_URL") } %>
    replica: true

  solid_queue:
    <<: *primary
    migrations_paths: db/solid_queue_migrate
    pool: <%= ENV.fetch("SOLID_QUEUE_POOL") { 10 } %>

2026 Production Cost, Timeline & Architecture Comparison

Choosing the right deployment strategy dictates your ongoing operational overhead and time-to-market. Below is an engineering comparison of managing custom Kamal 2 infrastructure versus alternative enterprise software architectures.

Frequently Asked Questions

How does Kamal 2 handle zero-downtime deployments across clustered web and worker nodes?

Kamal 2 utilizes Traefik as a smart reverse proxy. During a deployment, Kamal pulls the new Docker image on target servers, boots the new container alongside the old one, and performs internal health checks against your /up endpoint. Once the new container passes health checks, Traefik seamlessly shifts inbound routing traffic with zero dropped connections, followed by a graceful shutdown of the legacy container.

Why choose Solid Queue over Redis-backed solutions like Sidekiq in a Kamal 2 deployment?

Solid Queue stores background jobs directly inside your relational database (PostgreSQL). This eliminates the need to provision, monitor, and scale a separate Redis cluster, simplifying your Kamal 2 infrastructure topology. Furthermore, it guarantees transactional integrity where job creation and database mutations happen within the exact same database transaction.

How does TechVinta assist with custom Kamal 2 production architectures?

TechVinta provides elite engineering services specializing in high-performance Ruby on Rails transformations. We design, audit, and deploy production-grade Kamal 2 clusters tailored to your exact traffic profiles. With our reliable 4-6 hour US timezone overlap, our senior developers collaborate seamlessly with your internal team to ensure bulletproof reliability, security hardening, and zero-downtime cutovers.