Ruby on Rails 8: Novos Recursos e Guia de Migração 2026

Ruby on Rails 8 representa o lançamento mais significativo desde o Rails 7, introduzindo substituições do Redis baseadas em banco de dados, autenticação nativa e um pipeline de deploy simplificado. Lançado em novembro de 2024 e agora maduro com o Rails 8.1 em outubro de 2025, o Rails 8 elimina dependências externas que anteriormente exigiam infraestrutura dedicada.

O Solid Trifecta: Infraestrutura Baseada em Banco de Dados

Antes do Rails 8, a maioria das aplicações em produção dependia do Redis para tarefas em segundo plano, cache e pub/sub de WebSocket. O Solid Trifecta substitui esses três componentes por adaptadores baseados em banco de dados que funcionam com PostgreSQL, MySQL e SQLite.

Essa mudança arquitetural reduz consideravelmente a complexidade operacional. Não é mais necessário monitorar, escalar e manter uma instância Redis. A contrapartida é o throughput: o Redis continua mais rápido para cenários de alto volume, mas para a grande maioria das aplicações, os adaptadores baseados em banco de dados entregam desempenho mais do que adequado.

Solid Queue para Tarefas em Segundo Plano

O Solid Queue substitui Sidekiq, Resque ou Delayed Job por um backend de Active Job baseado em banco de dados. Ele utiliza FOR UPDATE SKIP LOCKED no PostgreSQL 9.5+, MySQL 8.0+, e possui um fallback elegante no SQLite.

# 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

O plugin do Puma inicia o Solid Queue junto com o servidor web em desenvolvimento, eliminando a necessidade de um processo separado:

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

O Solid Queue suporta tarefas recorrentes, controles de concorrência e funcionalidades críticas como pausar e retomar por fila. Para aplicações que processam menos de 10.000 tarefas por minuto, a carga é absorvida sem problemas.

Solid Cache e Solid Cable

O Solid Cache armazena caches de fragmentos HTML no banco de dados em vez do Memcached ou Redis. O armazenamento em disco (SSD/NVMe) custa uma fração do preço da RAM, permitindo pools de cache maiores com retenção mais longa. O Basecamp opera um Solid Cache de 10 TB com retenção de 60 dias em produção.

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

O Solid Cable substitui o adaptador pub/sub do Redis para o Action Cable. As mensagens WebSocket são escritas em uma tabela do banco de dados e consultadas a cada 100 ms por padrão. O resultado é praticamente em tempo real para a maioria dos casos de uso, com mensagens removidas após 24 horas.

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

Gerador de Autenticação Integrado

O Rails 8 inclui um gerador de autenticação nativo que produz um scaffolding completo: login baseado em sessão, logout e redefinição de senha. Nenhuma gem externa é necessária para autenticação básica.

# Gerar o scaffolding de autenticação
bin/rails generate authentication

Esse comando cria o modelo User, o modelo Session, o SessionsController, o PasswordsController e um concern Authentication. O código gerado utiliza has_secure_password com bcrypt e inclui limitação de taxa (10 tentativas de login a cada 3 minutos por IP).

# 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

As redefinições de senha utilizam tokens assinados e com tempo limitado, gerados pelo has_secure_password, em vez de tokens armazenados no banco de dados. O gerador intencionalmente não inclui cadastro, verificação de e-mail nem login social. O código gerado serve como uma base para expandir, não como um substituto do Devise.

Tratamento de Parâmetros Mais Seguro com params.expect

O Rails 8 introduz params.expect, uma alternativa mais segura ao padrão params.require.permit. O novo método lança uma exceção quando as chaves estão ausentes, em vez de retornar nil silenciosamente.

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

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

O método expect verifica que a chave :user existe e contém apenas os atributos permitidos. Se a chave estiver ausente, ele lança ActionController::ParameterMissing imediatamente, prevenindo bugs silenciosos no fluxo posterior.

Propshaft: O Novo Pipeline de Assets Padrão

O Propshaft substitui o Sprockets como pipeline de assets padrão. Enquanto o Sprockets gerenciava compilação, minificação e fingerprinting em um sistema monolítico, o Propshaft foca exclusivamente em servir e aplicar fingerprinting em assets estáticos.

Para o bundling de JavaScript, o Propshaft delega para ferramentas modernas: esbuild, Vite ou Bun. O processamento de CSS passa pelo Tailwind CLI ou dart-sass. O resultado é um pipeline mais rápido e previsível, alinhado com as ferramentas frontend atuais.

# Gemfile (Rails 8 padrão)
gem "propshaft"

# Nenhuma configuração necessária para uso básico
# Assets em app/assets são servidos e recebem fingerprinting automaticamente

Aplicações existentes que usam Sprockets podem continuar usando. O caminho de migração envolve remover as diretivas específicas do Sprockets (//= require) e utilizar import maps ou um bundler JavaScript.

Kamal 2 e Thruster: Deploy sem Downtime

O Rails 8 vem pré-configurado com o Kamal 2, uma ferramenta de deploy que transforma um servidor Linux novo em um servidor de produção com um único comando. O Kamal 2 substitui o Traefik pelo Kamal Proxy, um reverse proxy desenvolvido especificamente para essa finalidade.

# Deploy em um servidor novo
kamal setup

# Deploys seguintes
kamal deploy

O Thruster fica posicionado entre o Kamal Proxy e o Puma, fornecendo aceleração X-Sendfile para downloads de arquivos, compressão automática de assets (gzip/brotli) e suporte HTTP/2. O Dockerfile gerado pelo Rails 8 inclui o Thruster por padrão.

# Trecho do Dockerfile gerado pelo Rails 8
RUN gem install thruster
CMD ["thrust", "./bin/rails", "server"]

Essa stack (Kamal 2 + Kamal Proxy + Thruster + Puma) gerencia terminação SSL, deploys sem downtime e reinícios progressivos sem serviços externos como Nginx ou HAProxy.

Suporte Aprimorado ao SQLite para Produção

O Rails 8 melhora o suporte ao SQLite para uso em produção. O pooling de conexões, o modo WAL e a concorrência aprimorada tornam o SQLite viável para aplicações de pequeno a médio porte. Combinado com o Solid Trifecta, uma aplicação Rails 8 em servidor único pode funcionar inteiramente com SQLite, sem um servidor de banco de dados externo.

# config/database.yml (configuração SQLite em produção)
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

Essa configuração executa toda a stack da aplicação a partir de quatro arquivos SQLite. O Kamal monta o diretório de armazenamento como um volume persistente, garantindo a sobrevivência dos dados durante reinícios de containers.

Atualização do Rails 7 para o Rails 8

O caminho de migração do Rails 7.2 para o Rails 8.0 é direto se a aplicação já trata os avisos de depreciação. Aplicações no Rails 7.0 ou 7.1 devem atualizar de forma incremental: 7.0 para 7.1, depois 7.2, depois 8.0.

Passo 1: Atualizar as Dependências

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

bundle update rails

Passo 2: Executar a Tarefa de Atualização

bin/rails app:update

Esse comando atualiza os arquivos de configuração para os padrões do Rails 8. Cada alteração deve ser revisada cuidadosamente usando git diff. As mudanças principais incluem o novo valor padrão de Regexp.timeout (1 segundo), o comportamento atualizado do db:migrate (carregamento de schema em bancos novos) e a configuração do Propshaft.

Passo 3: Lidar com a Reordenação do Schema

O Rails 8 reordena as colunas do schema.rb para corresponder à ordem real das colunas no banco de dados. Recomenda-se executar o dump do schema imediatamente para isolar esse diff cosmético das mudanças reais de migração:

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

Passo 4: Adotar os Novos Recursos de Forma Incremental

O Solid Trifecta, o Propshaft e o gerador de autenticação são opcionais para aplicações existentes. A adoção deve ser feita individualmente após a atualização principal estar estável:

1. Substituir o adaptador de jobs pelo Solid Queue
2. Trocar o cache store para o Solid Cache
3. Migrar o Action Cable para o Solid Cable (se aplicável)
4. Avaliar a migração para o Propshaft no pipeline de assets

Passo 5: Atualizar o Tratamento de Parâmetros

Substituir as chamadas params.require.permit por params.expect nos controllers. Essa mudança é opcional, mas recomendada para uma validação de parâmetros mais rigorosa.

Rails 8.1: Jobs Continuáveis e CI Integrado

O Rails 8.1, lançado em outubro de 2025, se apoia nas bases do Rails 8 com duas funcionalidades principais. Os jobs continuáveis (ActiveJob::Continuable) dividem tarefas de longa duração em etapas retomáveis. Se um servidor reiniciar durante uma importação, o job retoma exatamente de onde parou, em vez de recomeçar do zero.

# 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

O Rails 8.1 também introduz configuração de CI integrada e renderização nativa de Markdown, reduzindo ainda mais as dependências externas.

Conclusão

• O Solid Trifecta (Queue, Cache, Cable) elimina o Redis como dependência obrigatória para jobs em segundo plano, cache e WebSockets
• O gerador de autenticação integrado fornece uma base para autenticação baseada em sessão sem gems de terceiros
• params.expect substitui params.require.permit com um tratamento de parâmetros mais rigoroso e seguro
• O Propshaft substitui o Sprockets como pipeline de assets padrão, delegando o bundling para ferramentas modernas
• O Kamal 2 e o Thruster oferecem deploy sem downtime sem Nginx ou Capistrano
• A atualização a partir do Rails 7.2 é incremental: atualizar dependências, executar app:update, adotar novos recursos um de cada vez
• O Rails 8.1 adiciona jobs continuáveis e CI integrado para equipes que buscam reduzir ferramentas externas