# Ruby on Rails 8: Нові можливості та повний гайд з міграції 2026

> Rails 8 впроваджує Solid Trifecta, вбудовану автентифікацію, Kamal 2 та Propshaft. Детальний посібник з прикладами коду та покроковою міграцією з Rails 7.

- Published: 2026-04-17
- Updated: 2026-04-17
- Author: SharpSkill
- Tags: ruby-on-rails, rails-8, tutorial, migration, solid-queue, solid-cache, authentication
- Reading time: 9 min

---

Ruby on Rails 8 знаменує собою переломний момент в історії фреймворку. Випущений у листопаді 2024 року та вдосконалений у Rails 8.1 у жовтні 2025 року, цей реліз усуває зовнішні залежності, які роками ускладнювали продакшн-архітектури. Redis, Sprockets, Capistrano — всі ці компоненти Rails 8 робить опціональними завдяки вбудованим альтернативам, що працюють безпосередньо з базою даних. Для розробників це означає значне спрощення розгортання, зниження витрат на інфраструктуру та нижчий поріг входження для проєктів середнього масштабу.

> **Rails 8 у двох словах**
>
> Rails 8 замінює Redis на Solid Trifecta (Solid Queue, Solid Cache, Solid Cable), включає нативний генератор автентифікації, використовує Propshaft як стандартний asset pipeline та інтегрує Kamal 2 для безперебійних деплоїв. Мінімальна версія Ruby — 3.2.

## Solid Trifecta: інфраструктура на базі даних

До Rails 8 кожен серйозний продакшн-застосунок залежав від Redis для трьох критичних функцій: фонових завдань, кешування та pub/sub для WebSocket. Solid Trifecta замінює всі три компоненти адаптерами, сумісними з PostgreSQL, MySQL та SQLite, що працюють безпосередньо з реляційною базою даних.

Оперативна перевага очевидна: більше не потрібно розгортати, моніторити та підтримувати окремий інстанс Redis. Компроміс стосується сирої продуктивності — Redis залишається швидшим у сценаріях з надвисоким навантаженням, але для переважної більшості застосунків адаптери на базі даних забезпечують достатню продуктивність. Basecamp, флагманський продукт 37signals, використовує Solid Cache обсягом 10 ТБ у продакшні з ретенцією 60 днів.

### Solid Queue: фонові завдання без Redis

Solid Queue замінює Sidekiq, Resque або Delayed Job як бекенд Active Job, що працює з базою даних. Він використовує `FOR UPDATE SKIP LOCKED` на PostgreSQL 9.5+ та MySQL 8.0+, з fallback-механізмом для SQLite.

```ruby
# config/environments/production.rb
config.active_job.queue_adapter = :solid_queue

# config/solid_queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      processes: 2
      polling_interval: 0.1
```

Плагін Puma запускає Solid Queue разом із веб-сервером у режимі розробки, що усуває необхідність окремого процесу:

```ruby
# config/puma.rb
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"] || Rails.env.development?
```

Solid Queue підтримує періодичні завдання, контроль конкурентності та розширені функції на кшталт призупинення та відновлення роботи черг. Для застосунків, що обробляють менше 10 000 завдань на хвилину, він справляється з навантаженням без проблем.

### Solid Cache та Solid Cable

Solid Cache зберігає кешовані HTML-фрагменти в базі даних замість Memcached або Redis. Зберігання на диску (SSD/NVMe) коштує значно менше за оперативну пам'ять, що дозволяє створювати набагато більші пули кешу з довшим терміном зберігання.

```ruby
# config/environments/production.rb
config.cache_store = :solid_cache_store
```

Solid Cable замінює Redis-адаптер pub/sub для Action Cable. WebSocket-повідомлення записуються в таблицю та опитуються кожні 100 мс за замовчуванням. Результат — майже реальний час комунікації для більшості випадків використання з автоматичним очищенням повідомлень через 24 години.

```yaml
# config/cable.yml
production:
  adapter: solid_cable
  polling_interval: 0.1
  keep_messages_around_for: 1.day
```

## Нативний генератор автентифікації

Rails 8 включає генератор автентифікації, який створює scaffolding для входу, виходу та скидання пароля. Жодних зовнішніх гемів не потрібно для базової автентифікації.

```bash
# Generate the authentication scaffolding
bin/rails generate authentication
```

Ця команда створює модель User, модель Session, SessionsController, PasswordsController та concern Authentication. Згенерований код використовує `has_secure_password` з bcrypt та включає rate limiting (10 спроб входу кожні 3 хвилини з однієї IP-адреси).

```ruby
# app/controllers/concerns/authentication.rb
module Authentication
  extend ActiveSupport::Concern

  included do
    before_action :require_authentication
    helper_method :authenticated?
  end

  private

  def require_authentication
    resume_session || request_authentication
  end

  def resume_session
    Current.session = find_session_by_cookie
  end

  def find_session_by_cookie
    Session.find_by(id: cookies.signed[:session_id]) if cookies.signed[:session_id]
  end

  def request_authentication
    session[:return_to_after_authenticating] = request.url
    redirect_to new_session_path
  end

  def authenticated?
    Current.session.present?
  end
end
```

Скидання пароля базується на підписаних токенах із терміном дії, згенерованих через `has_secure_password`, а не на токенах, що зберігаються в базі даних. Генератор навмисно не включає реєстрацію, підтвердження email чи соціальну автентифікацію. Згенерований код є міцною основою для розширення, а не повноцінною заміною Devise.

> **Межі генератора**
>
> Нативний генератор охоплює вхід, вихід та скидання пароля. Реєстрацію користувачів, підтвердження email, OAuth та багатофакторну автентифікацію потрібно додавати вручну або через геми на кшталт Authentication Zero.

## Безпечна обробка параметрів з params.expect

Rails 8 представляє `params.expect` — більш сувору альтернативу традиційному `params.require.permit`. Новий підхід викидає виняток, коли ключі відсутні, замість мовчазного повернення `nil`.

```ruby
# Before (Rails 7)
def user_params
  params.require(:user).permit(:name, :email, :role)
end

# After (Rails 8)
def user_params
  params.expect(user: [:name, :email, :role])
end
```

Метод `expect` гарантує, що ключ `:user` існує і містить лише дозволені атрибути. У разі відсутності він негайно викидає `ActionController::ParameterMissing`, що запобігає тихим помилкам далі в потоці виконання.

## Propshaft: новий стандартний asset pipeline

Propshaft замінює Sprockets як стандартний asset pipeline. Там, де Sprockets обробляв компіляцію, мініфікацію та fingerprinting у монолітній системі, Propshaft зосереджується виключно на обслуговуванні та fingerprinting статичних файлів.

Для бандлінгу JavaScript Propshaft делегує сучасним інструментам: esbuild, Vite або Bun. Обробка CSS відбувається через Tailwind CLI або dart-sass. Результат — швидший, передбачуваніший asset pipeline, що відповідає сучасній frontend-екосистемі.

```ruby
# Gemfile (Rails 8 default)
gem "propshaft"
```

Існуючі застосунки, що використовують Sprockets, можуть продовжувати це робити без обмежень. Міграція полягає у видаленні специфічних для Sprockets директив (`//= require`) та переході на import maps або JavaScript-бандлер.

## Kamal 2 та Thruster: безперебійне розгортання

Rails 8 попередньо налаштований з Kamal 2 — інструментом розгортання, здатним перетворити чистий Linux-сервер на продакшн-сервер однією командою. Kamal 2 замінює Traefik на Kamal Proxy — реверс-проксі, спеціально розроблений для цього випадку використання.

```bash
kamal setup
kamal deploy
```

Thruster розташовується між Kamal Proxy та Puma. Він забезпечує X-Sendfile прискорення для завантаження файлів, автоматичне стиснення ассетів (gzip/brotli) та підтримку HTTP/2. Dockerfile, згенерований Rails 8, включає Thruster за замовчуванням.

```dockerfile
RUN gem install thruster
CMD ["thrust", "./bin/rails", "server"]
```

Цей технологічний стек (Kamal 2 + Kamal Proxy + Thruster + Puma) обробляє SSL-термінацію, деплої без простою та поступові перезапуски без зовнішніх сервісів на кшталт Nginx чи HAProxy.

## Покращена підтримка SQLite для продакшну

Rails 8 значно покращує підтримку SQLite у продакшні. Connection pooling, WAL-режим та покращена конкурентність роблять SQLite життєздатним для малих та середніх застосунків. У поєднанні з Solid Trifecta один сервер може запустити повноцінний Rails 8 застосунок виключно на SQLite, без жодного зовнішнього сервера бази даних.

```yaml
# config/database.yml (SQLite production setup)
production:
  primary:
    adapter: sqlite3
    database: storage/production.sqlite3
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  cache:
    adapter: sqlite3
    database: storage/production_cache.sqlite3
  queue:
    adapter: sqlite3
    database: storage/production_queue.sqlite3
  cable:
    adapter: sqlite3
    database: storage/production_cable.sqlite3
```

Ця конфігурація запускає весь application stack із чотирьох SQLite-файлів. Kamal монтує директорію storage як persistent volume, гарантуючи збереження даних при перезапусках контейнерів.

## Міграція з Rails 7 на Rails 8

Міграція з Rails 7.2 на Rails 8.0 проходить гладко за умови, що застосунок попередньо виправив усі deprecation warnings. Застосунки на Rails 7.0 або 7.1 повинні мігрувати поетапно: з 7.0 на 7.1, потім з 7.1 на 7.2, і нарешті з 7.2 на 8.0.

> **Передумови для перевірки**
>
> Rails 8 вимагає Ruby 3.2 або новішої версії. Необхідно перевірити встановлену версію Ruby, переконатися, що тести проходять на Rails 7.2, та перевірити сумісність гемів через RailsBump перед оновленням.

### Крок 1: оновлення залежностей

```ruby
# Gemfile
gem "rails", "~> 8.0"
```

```bash
bundle update rails
```

### Крок 2: виконання задачі оновлення

```bash
bin/rails app:update
```

Ця команда оновлює конфігураційні файли до значень за замовчуванням Rails 8. Важливо переглянути кожну зміну через `git diff`. Помітні зміни включають нове значення за замовчуванням `Regexp.timeout` (1 секунда), змінену поведінку `db:migrate` (завантаження схеми для порожніх баз даних) та конфігурацію Propshaft.

### Крок 3: обробка реорганізації схеми

Rails 8 переупорядковує колонки в `schema.rb` відповідно до реального порядку колонок у базі даних. Рекомендується виконати dump схеми одразу, щоб ізолювати цю косметичну зміну від справжніх змін міграцій:

```bash
bin/rails db:schema:dump
git add db/schema.rb
git commit -m "Reorder schema columns for Rails 8"
```

### Крок 4: поступове впровадження нових можливостей

Solid Trifecta, Propshaft та генератор автентифікації залишаються опціональними для існуючих застосунків. Рекомендується впроваджувати їх індивідуально після стабілізації основного оновлення:

1. Замінити адаптер завдань на Solid Queue
2. Перевести cache store на Solid Cache
3. Мігрувати Action Cable на Solid Cable (за потреби)
4. Оцінити міграцію asset pipeline на Propshaft

### Крок 5: модернізація обробки параметрів

Замінити виклики `params.require.permit` на `params.expect` у всіх контролерах. Ця зміна опціональна, але наполегливо рекомендована для більш надійної валідації параметрів.

## Rails 8.1: Continuable Jobs та вбудований CI

Rails 8.1, випущений у жовтні 2025 року, розширює фундамент Rails 8 двома визначними функціями. Continuable Jobs (`ActiveJob::Continuable`) розбивають тривалі завдання на етапи, що автоматично відновлюються. Якщо сервер перезавантажується посеред імпорту, завдання продовжується з того місця, де зупинилося, замість перезапуску з нуля.

```ruby
# app/jobs/import_records_job.rb
class ImportRecordsJob < ApplicationJob
  include ActiveJob::Continuable

  def perform(cursor:)
    records = Record.where("id > ?", cursor.value || 0).limit(1000)

    records.each do |record|
      process(record)
      cursor.advance(record.id)
    end
  end
end
```

Rails 8.1 також представляє вбудовану CI-конфігурацію та нативний рендеринг Markdown, ще більше зменшуючи зовнішні залежності.

## Висновок

Rails 8 являє собою значний зсув у філософії фреймворку, віддаючи пріоритет операційній простоті без компромісів щодо функціональності. Ключові моменти:

- Solid Trifecta (Queue, Cache, Cable) усуває Redis як обов'язкову залежність для завдань, кешування та WebSocket
- Нативний генератор автентифікації надає основу для сесійної автентифікації без сторонніх гемів
- `params.expect` замінює `params.require.permit` на більш сувору та безпечну обробку параметрів
- Propshaft заміщує Sprockets як стандартний asset pipeline, делегуючи бандлінг сучасним інструментам
- Kamal 2 та Thruster забезпечують безперебійні деплої без Nginx чи Capistrano
- Міграція з Rails 7.2 є інкрементальною: оновлення залежностей, виконання `app:update` та поступове впровадження нових можливостей
- Rails 8.1 додає Continuable Jobs та вбудований CI для команд, що прагнуть скоротити зовнішні інструменти

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/ruby-on-rails/ruby-on-rails-8-new-features-migration-guide