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

> Ruby on Rails 8 traz o Solid Trifecta, um gerador de autenticação nativo, Kamal 2 e Propshaft. Este tutorial aborda cada recurso principal e detalha a atualização a partir do Rails 7 passo a passo.

- Published: 2026-04-17
- Updated: 2026-04-17
- Author: SharpSkill
- Tags: ruby-on-rails, rails-8, tutorial, migração, solid-queue, solid-cache, autenticação
- Reading time: 9 min

---

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.

> **Rails 8 em Resumo**
>
> O Rails 8 substitui o Redis pelo Solid Trifecta (Solid Queue, Solid Cache, Solid Cable), adiciona um gerador de autenticação integrado, troca o pipeline de assets padrão para o Propshaft e inclui o Kamal 2 para deploy sem downtime. Ruby 3.2+ é obrigatório.

## 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.

```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
```

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

```ruby
# 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.

```ruby
# 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.

```yaml
# 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.

```bash
# 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).

```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
```

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.

> **Escopo da Autenticação**
>
> O gerador integrado cobre login, logout e redefinição de senha. Cadastro, verificação de e-mail, OAuth e MFA devem ser adicionados manualmente ou por meio de gems como Authentication Zero.

## 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.

```ruby
# 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.

```ruby
# 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.

```bash
# 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.

```dockerfile
# 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.

```yaml
# 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.

> **Checklist Pré-Atualização**
>
> O Rails 8 requer Ruby 3.2+. É fundamental verificar a versão do Ruby, garantir que os testes passem no Rails 7.2 e checar a compatibilidade das gems com o RailsBump antes de iniciar a atualização.

### Passo 1: Atualizar as Dependências

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

```bash
bundle update rails
```

### Passo 2: Executar a Tarefa de Atualização

```bash
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:

```bash
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.

```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
```

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

---

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