# How to Deploy a Ruby on Rails App in 2026: Complete Guide > Deploy a Ruby on Rails app from GitHub with Kuberns. Configure PostgreSQL, Rails credentials, migrations, assets, background jobs, storage, and HTTPS. - **Author**: parth-kanpariya - **Published**: 2026-04-20 - **Modified**: 2026-10-02 - **Category**: Deployment Guides - **URL**: https://kuberns.com/blogs/how-to-deploy-ruby-on-rails-app/ --- The simplest way to deploy a Ruby on Rails app is to prepare the repository for production, push it to GitHub, connect it to a managed deployment platform, add the Rails credentials and database connection, and verify the application after release. A real Rails deployment must account for the web process, database migrations, assets, background jobs, uploads, health checks, and HTTPS. For developers who do not want to operate a VPS or configure a container orchestrator, [Kuberns](https://kuberns.com/) provides a GitHub-to-production workflow. Kuberns is an Agentic AI platform for deployment that detects application configuration, lets the team review its build and process settings, and manages the build, runtime, resources, logs, and production endpoint. This guide explains what a modern Rails application needs in production, how to deploy it from GitHub through Kuberns, how to configure PostgreSQL and background jobs, how managed platforms compare with Kamal, and what to test before sending users to the new release. ## TL;DR: How to Deploy a Ruby on Rails App - Confirm the Ruby and Rails versions, commit `Gemfile.lock`, and test the production configuration locally. - Keep `config/master.key`, database passwords, and API keys outside the repository. - Push the application to GitHub and connect its production branch to Kuberns. - Add `RAILS_MASTER_KEY` or `SECRET_KEY_BASE` and the other required environment variables. - Add a PostgreSQL resource or connect an external database through `DATABASE_URL`. - Review the detected build, migration, asset, and start commands before deploying. - Add a separate process for Solid Queue or Sidekiq when jobs should not run inside the web process. - Verify `/up`, migrations, assets, uploads, jobs, WebSockets, logs, HTTPS, and the production domain. ## What Does a Rails App Need in Production? Modern Rails applications include more production support than older guides suggest, but the deployment still has to coordinate several components. The [official Rails guide](https://guides.rubyonrails.org/getting_started.html#deploying-to-production) uses Kamal with the production-ready Dockerfile generated for a new application. A managed platform follows a different operational model, but the application requirements remain similar. | Requirement | What to check before deployment | |---|---| | Ruby and Rails versions | Pin a supported Ruby version and commit `Gemfile.lock` | | Web process | Confirm Puma or the selected Rack server starts in production | | Rails credentials | Provide `RAILS_MASTER_KEY` or the secrets expected by the app | | Database | Use a durable production database and provide `DATABASE_URL` | | Migrations | Decide when `bin/rails db:prepare` or `db:migrate` runs | | Assets | Confirm the selected Propshaft, Sprockets, or frontend build completes | | Health check | Keep the Rails `/up` endpoint available or provide an equivalent endpoint | | Background jobs | Configure Solid Queue or a Sidekiq worker with Redis | | File uploads | Use durable object storage for Active Storage when local disk is ephemeral | | Realtime features | Configure Action Cable and its production adapter when the app uses WebSockets | | Operations | Enable HTTPS, logs, metrics, rollback, and backups | ### Prepare the Rails Repository Confirm that the production dependencies and lockfile are committed. Puma is the standard web server for current Rails applications, but its workers and threads should fit the available CPU, memory, and database connection pool. Do not copy a fixed concurrency value from another application without checking those limits. New Rails applications commonly use encrypted credentials. If the application reads `config/credentials.yml.enc`, provide `RAILS_MASTER_KEY` in the deployment environment and never commit `config/master.key`. Older or customized applications may read `SECRET_KEY_BASE` directly. For the database, prefer a configuration that reads the production connection from the environment: ```yaml production: url: <%= ENV.fetch("DATABASE_URL") %> pool: <%= ENV.fetch("RAILS_MAX_THREADS", 5) %> ``` Run the test suite and a production-like boot locally before deploying. If the repository includes the Rails-generated Dockerfile, build it locally when possible. Confirm that the application can start with production credentials and that `bin/rails db:prepare` and the asset build complete against a disposable environment. ### Plan Migrations Before Automating Them Database migrations should run once for a release, not independently in every web replica. A release or pre-deploy command is the safest place for routine migrations. Long-running, destructive, or locking migrations need separate review and may require an expand-contract rollout so the old and new application versions can use the schema safely. If database changes have caused previous incidents, review the common reasons [software deployments fail](https://kuberns.com/blogs/why-do-software-deployments-fail/) before deciding which migration checks belong in the release workflow. ## Best Way to Deploy a Rails App From GitHub ![Kuberns Agentic AI platform for deployment](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png) Kuberns is suitable when the goal is to deploy a Rails repository without maintaining an Ubuntu server, reverse proxy, certificate renewal process, or container orchestration layer. The platform can inspect the repository and identify framework, dependency, port, build, and process information, but the developer should still review the detected settings and validate application behavior. ### Step 1: Prepare the Rails Repository Before connecting the project, confirm the following: - The Rails application starts locally with the committed lockfile. - The Ruby version is declared in the repository. - Secrets and `config/master.key` are excluded from Git. - The production health endpoint responds correctly. - Database and asset commands work in a production-like environment. - Any worker or scheduled process has a documented start command. ### Step 2: Push the Application to GitHub Commit the application code, lockfile, migrations, asset configuration, and deployment files. Push the branch that should represent production. A connected Git workflow also makes later releases repeatable; the guide to [automatic deployment from GitHub](https://kuberns.com/blogs/how-to-auto-deploy-your-apps-from-github-in-one-click/) explains how repository changes enter that workflow. ### Step 3: Connect the Repository to Kuberns Sign in to Kuberns, choose a GitHub deployment source, authorize the Kuberns GitHub App for the required repository, and select the repository and branch. The agent analyzes the project and proposes deployment configuration based on the files it detects. Review the runtime version, root directory, build command, start command, port, and resource requirements. Detection reduces setup work, but it should not replace review by someone who understands the Rails application. ### Step 4: Configure Rails Credentials and Resources Add the secrets and configuration the application expects. Common values include: ```text RAILS_ENV=production RAILS_MASTER_KEY= RAILS_LOG_TO_STDOUT=true DATABASE_URL= ``` Add only the variables the application actually reads. Kuberns supports environment-level variables, and its documentation explains how to [configure environment variables](https://docs.kuberns.com/docs/guides/environment-variables) without putting secrets in the repository. From the environment resources, add PostgreSQL or connect a compatible external provider. Keep the database in an appropriate region, use TLS when the provider requires it, and confirm the connection pool can support the planned Puma and worker concurrency. ### Step 5: Review Commands and Deploy Confirm the build and process plan before starting the deployment. Depending on the application, the workflow may need to install gems, compile assets, run a controlled database preparation command, and start the Rails server. Do not assume every migration is safe merely because it can run automatically. Start the deployment and follow the build logs. If the build fails, fix the identified dependency, credential, asset, or command issue rather than repeatedly redeploying unchanged code. ### Step 6: Verify the Production Application A successful build does not prove the complete Rails application works. After deployment: 1. Open `/up` and the main application routes. 2. Confirm the expected migrations ran exactly once. 3. Test CSS, JavaScript, images, and any frontend build output. 4. Perform a database write and read through the application. 5. Upload and retrieve a file if Active Storage is used. 6. Enqueue and complete a background job. 7. Test Action Cable connections if the app uses WebSockets. 8. Review runtime logs and resource metrics. 9. Verify HTTPS, redirects, and the custom domain. 10. Confirm the team knows how to restore the previous application version and database backup. ## Configure PostgreSQL, Background Jobs, and Storage ### PostgreSQL Use the Kuberns Resources section to add a PostgreSQL datastore or supply the connection string from an external PostgreSQL provider. The application should read that value from `DATABASE_URL`. Treat backups, retention, restore tests, extensions, connection limits, and database-region selection as separate production decisions rather than assuming the connection string solves them. ### Solid Queue and Sidekiq Rails 8 uses Solid Queue as its production Active Job backend in the default application setup. Solid Queue stores jobs in a database and can run in a separate process. The official Rails guide also documents a simpler Puma-integrated mode for smaller deployments, but a separate worker gives busy applications clearer resource isolation. Applications already using Sidekiq can continue to use it. Add Redis, create a background-worker resource, use `bundle exec sidekiq` as the worker command, and provide the same Rails credentials and application configuration required by the web service. The guide to [deploying services and background workers](https://kuberns.com/blogs/how-to-deploy-microservices-without-managing-multiple-tools/) explains why each process needs its own command, resources, and logs. ### Scheduled Jobs Do not run a scheduler independently in every web replica. Use a single scheduler process, a platform cron resource, or a job system with leader coordination. Make scheduled work idempotent so retrying a failed run does not duplicate billing, messages, or data changes. ### Active Storage Local container files can disappear during replacement or scaling. Configure Active Storage with durable object storage for production uploads. Store the bucket credentials and region as environment variables, limit permissions to the required bucket operations, and verify direct uploads, downloads, variants, and cleanup tasks after deployment. ### Action Cable If the application uses Action Cable, confirm the production adapter and allowed request origins. Test reconnect behavior during a deployment and decide whether Redis or the Rails-native database-backed option fits the application. A normal page load does not validate long-lived WebSocket connections. ## Compare Rails Deployment Options The right option depends on whether the team wants a managed Git workflow or direct control of servers and containers. | Option | Deployment model | PostgreSQL and workers | Configuration ownership | Best fit | |---|---|---|---|---| | Kuberns | Connect a Git repository, review detected settings, and use managed resources | PostgreSQL, Redis, and background-worker resources can share an environment | Platform manages deployment infrastructure; team owns app configuration and release safety | Teams wanting a managed GitHub-to-production workflow | | Kamal | Deploy the Rails-generated container to servers you control | Team provisions and operates database and job infrastructure | Team owns servers, registry, networking, backups, and deployment configuration | Rails teams wanting infrastructure control | | Heroku | Git or container deployment using the Ruby buildpack and process model | Add-ons and separate process types | Platform manages runtime; team declares application processes and services | Existing Heroku workflows and add-on users | | Render | Managed web services with explicit build, pre-deploy, and start commands | Managed PostgreSQL and separate workers | Team supplies Rails build and service configuration | Teams comfortable with explicit service setup | | Railway | GitHub, CLI, template, or Docker deployment | PostgreSQL, Redis, workers, cron, Solid Queue, and Sidekiq patterns are documented | Team reviews service commands and connects resources | Rapid prototypes and configurable multi-service projects | Kamal is the official Rails path when the team wants to deploy directly to its own server. Managed platforms reduce server administration, but they do not remove responsibility for credentials, migrations, background work, data recovery, and application-level compatibility. Railway’s [Rails deployment documentation](https://docs.railway.com/guides/rails) and Render’s [Rails 8 guide](https://render.com/docs/deploy-rails-8) are useful primary references when comparing their current workflows. ## Verify and Troubleshoot the Deployment When a Rails release fails, identify whether the problem occurs during the build, release, startup, or runtime stage. | Symptom | Likely cause | What to check | |---|---|---| | Missing credentials error | `RAILS_MASTER_KEY` or required secret is absent | Environment-variable names and encrypted credentials | | Database connection failure | Invalid URL, TLS requirement, network access, or exhausted pool | `DATABASE_URL`, provider settings, pool size, and region | | Migration failure | Lock, incompatible migration, missing extension, or wrong database | Migration logs and database permissions | | Assets return 404 | Asset or frontend build did not run, or paths are incorrect | Build logs, asset manifest, and production asset settings | | App starts but health check fails | Wrong port, slow boot, or broken `/up` route | Runtime logs, bind address, port, and health endpoint | | Jobs remain queued | Worker is absent, stopped, or pointed at the wrong backend | Worker logs, queue adapter, database or Redis URL | | Uploads disappear | Files are stored on ephemeral local disk | Active Storage service and object-storage credentials | | WebSockets disconnect | Adapter, origin, proxy, or timeout configuration is wrong | Action Cable settings and connection logs | Keep the previous stable application version available and maintain a tested database backup and restore process. Application rollback and data rollback are different operations. The [deployment rollback guide](https://kuberns.com/blogs/how-to-rollback-a-deployment/) explains how to plan both before an incident. ## Conclusion A production Rails deployment succeeds when the repository, credentials, database, migrations, assets, background jobs, storage, health checks, and runtime are treated as one operating system rather than independent setup tasks. Modern Rails provides strong defaults through Puma, Docker, Kamal, Solid Queue, and `/up`, while managed platforms reduce the infrastructure a team has to run itself. Kuberns is the best fit when you want to connect a Rails repository from GitHub, review the detected configuration, add PostgreSQL and supporting resources, and manage the application from one deployment environment. The platform handles the deployment workflow, while your team retains control of application behavior, migration safety, credentials, and production verification. Deploy a Ruby on Rails application with Kuberns ## Frequently Asked Questions ### What is the easiest way to deploy a Ruby on Rails app? For teams that do not want to manage a server, the easiest route is to prepare the Rails repository, push it to GitHub, connect it to a managed deployment platform, add Rails credentials and PostgreSQL, review the detected commands, deploy, and verify the production services. ### What does a Rails app need in production? A production Rails app needs a supported Ruby runtime, a web process such as Puma, Rails credentials, a production database, compiled assets, HTTPS, logs, health checks, and a durable background-job setup when the application runs asynchronous work. ### Should I use `RAILS_MASTER_KEY` or `SECRET_KEY_BASE`? Use `RAILS_MASTER_KEY` when the application relies on Rails encrypted credentials. `SECRET_KEY_BASE` can be supplied directly when the application expects it. Never commit `config/master.key` or secret values to the repository. ### How should Rails database migrations run during deployment? Run `bin/rails db:prepare` or `bin/rails db:migrate` as a controlled release or pre-deploy command before the new application version receives traffic. Review destructive or long-running migrations separately rather than assuming every migration is safe to automate. ### Can Rails use PostgreSQL on Kuberns? Yes. Add a PostgreSQL resource to the Kuberns environment or connect a compatible external PostgreSQL provider, then supply its connection string through `DATABASE_URL`. ### Do Rails 8 apps need Sidekiq and Redis? Not necessarily. Rails 8 supports Solid Queue, which stores jobs in a database. Applications already using Sidekiq can continue running a separate worker process with Redis. ### Do I need Docker or a Procfile to deploy Rails? It depends on the deployment target. New Rails applications include a production Dockerfile for Kamal and container platforms. Some managed platforms can detect and run Rails without a Procfile, while others let you declare explicit commands. ### How do I know whether the Rails deployment succeeded? Check the build and runtime logs, open the Rails health endpoint, confirm database migrations, test asset delivery and uploads, run a background job, verify WebSockets if used, and test the production domain over HTTPS. --- - [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/) - [All articles](https://kuberns.com/blogs/)