Deployment, Puma and performance

Rails 8 apps are deployed as Docker containers with Kamal 2. config/deploy.yml lists servers, the image registry and environment secrets (.kamal/secrets). kamal setup prepares fresh servers, and kamal deploy builds the image, pushes it, boots new containers and switches traffic through kamal-proxy with zero downtime and automatic Let's Encrypt TLS. Accessories run databases or Redis next to the app. Heroku, Render and Fly.io remain alternatives.

Puma serves requests with processes and threads:

• WEB_CONCURRENCY sets workers (forked processes). Use roughly one per CPU core for real parallelism, since the GVL lets only one thread run Ruby at a time per process.
• RAILS_MAX_THREADS sets threads per worker (default 3 since Rails 7.2). Threads overlap I/O waits (database, HTTP) but compete for the GVL, so more threads raises throughput and also latency.
• preload_app! loads the app before forking so workers share memory via copy-on-write.

The database connection pool (pool: in database.yml) must be at least the number of threads that use the database in each process, including Solid Queue threads if they run inside Puma; otherwise threads wait for connections and time out.

Production checklist: enable YJIT (on by default when available), serve assets with long cache headers via Thruster or a CDN, keep jobs off the web process for heavy loads, and watch p95 and p99 latency, not averages. Find bottlenecks with an APM or open-source tools: rack-mini-profiler, query logs with config.active_record.query_log_tags_enabled, and bin/rails logs showing time spent in views versus Active Record.