CI/CD for Ruby on Rails with GitHub Actions

By Khimananda Oli | Last reviewed: August 2026

Shipping Ruby on Rails applications reliably requires automating tests, security checks, and deployments from the moment code is pushed. CI/CD for Ruby on Rails with GitHub Actions provides a native, YAML-driven pipeline that integrates directly with your repository without external Jenkins servers or complex plugin management. This guide walks you through building a production-grade workflow that handles dependency caching, parallel testing, and safe deployments.

Before writing any workflow files, understand that effective automation mirrors your local development environment while enforcing stricter quality gates. If you are also evaluating infrastructure choices or comparing platforms, reading GitHub Actions vs GitLab CI comparison helps clarify trade-offs. For Rails specifically, GitHub Actions offers superior caching primitives and seamless integration with the broader GitHub ecosystem, making it the default choice for most teams in 2026.

How do you configure CI/CD for Ruby on Rails with GitHub Actions?

Configuration starts with creating a workflow file at .github/workflows/ci.yml. The most common mistake I see in audits is skipping service containers for databases, leading to flaky tests that pass locally but fail in CI. Always define your PostgreSQL or MySQL container explicitly within the workflow rather than relying on SQLite unless your production stack actually uses it.

Core workflow structure

A minimal but complete workflow triggers on pushes to main and pull requests. It sets environment variables for Rails, configures the database service, and runs bundle install with caching enabled. Here is a tested configuration for Rails 8.x with Ruby 3.4:

<!-- .github/workflows/ci.yml -->
name: Rails CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  RAILS_ENV: test
  DATABASE_URL: postgres://postgres:postgres@localhost:5432/rails_test
  BUNDLE_JOBS: 4
  BUNDLE_RETRY: 3

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: rails_test
        ports:
          - 5432:5432
        options: >-
          --health-cmd="pg_isready -U postgres"
          --health-interval=10s
          --health-timeout=5s
          --health-retries=5
    steps:
      - uses: actions/checkout@v4
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.4'
          bundler-cache: true
      - name: Prepare database
        run: bin/rails db:test:prepare
      - name: Run tests
        run: bundle exec rspec --format progress
      - name: Security scan
        run: bundle exec brakeman -q --no-pager

The ruby/setup-ruby@v1 action with bundler-cache: true automatically caches gems based on your Gemfile.lock hash. This single line typically reduces build times by 60–90 seconds per run. Never manually cache the vendor/bundle directory anymore; the official action handles invalidation correctly across OS and Ruby version changes.

How do you optimize Rails test performance in GitHub Actions?

Slow CI kills developer velocity. In practice, Rails test suites exceeding 10 minutes indicate missing parallelization or inefficient setup. GitHub Actions supports matrix strategies and native test splitting that can cut wall-clock time dramatically without changing application code.

Parallel test execution with matrix builds

Split your test suite across multiple runners using the matrix strategy combined with the knapsack_pro gem or built-in RSpec sharding. This distributes specs evenly based on historical timing data rather than naive file count splitting:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        ci_node_total: [4]
        ci_node_index: [0, 1, 2, 3]
    env:
      KNAPSACK_PRO_CI_NODE_TOTAL: ${{ matrix.ci_node_total }}
      KNAPSACK_PRO_CI_NODE_INDEX: ${{ matrix.ci_node_index }}
      KNAPSACK_PRO_RSPEC_SPLIT_BY_TEST_EXAMPLES: true
    steps:
      - uses: actions/checkout@v4
      - name: Run parallel tests
        run: bundle exec knapsack_pro:rspec

For teams not ready to adopt Knapsack Pro, RSpec 3.12+ includes native sharding via --shard N/M. While less optimal than timing-based distribution, it requires zero additional dependencies and still provides significant speedups for large suites. Combine this with build caching strategies to keep cold starts under two minutes.

How do you handle secrets and secure deployments in Rails CI?

Hardcoding AWS keys or database passwords in GitHub Secrets is a compliance failure waiting to happen. Modern CI/CD for Ruby on Rails with GitHub Actions should use OpenID Connect (OIDC) for cloud authentication and encrypted secrets management for application credentials. This eliminates long-lived credentials entirely and satisfies SOC 2 and ISO 27001 audit requirements.

OIDC authentication for AWS deployments

Configure an IAM Identity Provider in AWS that trusts your GitHub repository's OIDC token. Then assume a role with minimal permissions during deployment:

deploy:
  needs: test
  if: github.ref == 'refs/heads/main'
  runs-on: ubuntu-latest
  permissions:
    id-token: write
    contents: read
  steps:
    - uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRailsDeploy
        aws-region: us-east-1
    - name: Deploy with Kamal
      run: |
        gem install kamal
        kamal deploy

This approach means no static access keys exist in your repository settings. The OIDC token is short-lived, scoped to the specific workflow run, and automatically rotated. For application secrets like API keys, integrate HashiCorp Vault or AWS Secrets Manager as described in handling secrets in CI/CD pipelines safely. Never store production database URLs or third-party tokens as plain GitHub Secrets if you are subject to compliance audits.

What are the best practices for Rails deployment automation?

Deployment strategy matters as much as the CI pipeline itself. Teams often over-engineer Kubernetes when a simpler VPS or container-based approach suffices. Choose your tooling based on actual scale requirements, not hype.

For most Rails applications serving Nepali or global SME audiences, Kamal 2 provides the best balance of simplicity and production readiness. It uses Docker, supports zero-downtime deployments via Traefik, and integrates cleanly with GitHub Actions OIDC. Reserve Kubernetes for workloads requiring auto-scaling beyond vertical limits or multi-region failover. If you do choose Kubernetes, follow blue-green and canary deploy patterns to avoid downtime during releases.

Database migration safety

Never run migrations blindly in the deploy step. Separate migration into its own job that runs before application deployment and includes rollback logic. Use strong_migrations gem to catch unsafe operations in CI, and always test migrations against a restored production dump in staging. Zero-downtime migrations require backward-compatible schema changes — add columns first, deploy code that writes to both old and new columns, backfill data, then drop the old column in a subsequent release.

Implementing CI/CD for Ruby on Rails with GitHub Actions

Building reliable CI/CD for Ruby on Rails with GitHub Actions requires attention to caching, parallelization, secret management, and deployment safety. Start with the base workflow provided above, add parallel testing once your suite exceeds five minutes, and migrate to OIDC authentication before your next compliance review. Monitor pipeline duration weekly and treat CI speed as a first-class metric alongside test coverage. If your team needs help designing audit-ready Rails pipelines or optimizing existing workflows, reach out to discuss your specific infrastructure.