Ruby on Rails 8: Nuevas Características y Guía de Migración 2026

Ruby on Rails 8 representa la versión más importante desde Rails 7, con reemplazos de Redis basados en base de datos, autenticación nativa y un pipeline de despliegue simplificado. Lanzada en noviembre de 2024 y ahora madura con la versión Rails 8.1 en octubre de 2025, esta actualización elimina las dependencias externas que anteriormente requerían infraestructura dedicada.

El Solid Trifecta: Infraestructura Respaldada por Base de Datos

Antes de Rails 8, la mayoría de las aplicaciones en producción dependían de Redis para tareas en segundo plano, caché y pub/sub de WebSocket. El Solid Trifecta reemplaza estos tres componentes con adaptadores respaldados por base de datos que funcionan con PostgreSQL, MySQL y SQLite.

Este cambio arquitectónico reduce significativamente la complejidad operativa. Ya no es necesario monitorear, escalar ni mantener una instancia de Redis. La contrapartida es el rendimiento: Redis sigue siendo más rápido para escenarios de alto volumen, pero para la gran mayoría de las aplicaciones, los adaptadores basados en base de datos ofrecen un rendimiento más que adecuado.

Solid Queue para Tareas en Segundo Plano

Solid Queue reemplaza Sidekiq, Resque o Delayed Job con un backend de Active Job respaldado por base de datos. Aprovecha FOR UPDATE SKIP LOCKED en PostgreSQL 9.5+, MySQL 8.0+, y funciona de manera elegante como fallback en 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

El plugin de Puma inicia Solid Queue junto con el servidor web en desarrollo, eliminando la necesidad de un proceso separado:

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

Solid Queue soporta tareas recurrentes, controles de concurrencia y funcionalidades críticas como pausar y reanudar por cola. Para aplicaciones que procesan menos de 10,000 tareas por minuto, maneja la carga sin inconvenientes.

Solid Cache y Solid Cable

Solid Cache almacena cachés de fragmentos HTML en la base de datos en lugar de Memcached o Redis. El almacenamiento en disco (SSD/NVMe) cuesta una fracción de la RAM, lo que permite pools de caché más grandes con mayor retención. Basecamp ejecuta un Solid Cache de 10 TB con retención de 60 días en producción.

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

Solid Cable reemplaza el adaptador pub/sub de Redis para Action Cable. Los mensajes WebSocket se escriben en una tabla de base de datos y se consultan cada 100 ms por defecto. Es prácticamente en tiempo real para la mayoría de los casos de uso, con mensajes purgados después de 24 horas.

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

Generador de Autenticación Integrado

Rails 8 incluye un generador de autenticación nativo que produce scaffolding completo: inicio de sesión basado en sesiones, cierre de sesión y restablecimiento de contraseña. No se requieren gemas externas para la autenticación básica.

# Generar el scaffolding de autenticación
bin/rails generate authentication

Este comando crea el modelo User, el modelo Session, el SessionsController, el PasswordsController y un concern Authentication. El código generado utiliza has_secure_password con bcrypt e incluye limitación de tasa (10 intentos de inicio de sesión por 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

Los restablecimientos de contraseña utilizan tokens firmados y con tiempo limitado generados por has_secure_password, en lugar de tokens almacenados en base de datos. El generador no incluye intencionalmente registro, verificación de correo electrónico ni inicio de sesión social. El código generado sirve como base para ampliar, no como un reemplazo de Devise.

Manejo de Parámetros Más Seguro con params.expect

Rails 8 introduce params.expect, una alternativa más segura al patrón params.require.permit. El nuevo método lanza una excepción cuando faltan claves, en lugar de retornar nil silenciosamente.

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

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

El método expect verifica que la clave :user exista y contenga solo los atributos permitidos. Si la clave no está presente, lanza ActionController::ParameterMissing de inmediato, previniendo errores silenciosos en el flujo posterior.

Propshaft: El Nuevo Pipeline de Assets por Defecto

Propshaft reemplaza a Sprockets como el pipeline de assets por defecto. Mientras que Sprockets manejaba la compilación, minificación y fingerprinting en un sistema monolítico, Propshaft se enfoca exclusivamente en servir y aplicar fingerprinting a los assets estáticos.

Para el bundling de JavaScript, Propshaft delega a herramientas modernas: esbuild, Vite o Bun. El procesamiento CSS pasa por Tailwind CLI o dart-sass. El resultado es un pipeline más rápido y predecible, alineado con las herramientas frontend actuales.

# Gemfile (Rails 8 por defecto)
gem "propshaft"

# No se necesita configuración para uso básico
# Los assets en app/assets se sirven y reciben fingerprinting automáticamente

Las aplicaciones existentes que usan Sprockets pueden continuar haciéndolo. La ruta de migración implica eliminar las directivas específicas de Sprockets (//= require) y utilizar import maps o un bundler de JavaScript.

Kamal 2 y Thruster: Despliegue Sin Tiempo de Inactividad

Rails 8 viene preconfigurado con Kamal 2, una herramienta de despliegue que convierte un servidor Linux nuevo en un servidor de producción con un solo comando. Kamal 2 reemplaza Traefik con Kamal Proxy, un reverse proxy diseñado específicamente para este propósito.

# Desplegar en un servidor nuevo
kamal setup

# Despliegues posteriores
kamal deploy

Thruster se ubica entre Kamal Proxy y Puma, proporcionando aceleración X-Sendfile para descargas de archivos, compresión automática de assets (gzip/brotli) y soporte HTTP/2. El Dockerfile generado por Rails 8 incluye Thruster por defecto.

# Fragmento del Dockerfile generado por Rails 8
RUN gem install thruster
CMD ["thrust", "./bin/rails", "server"]

Esta stack (Kamal 2 + Kamal Proxy + Thruster + Puma) maneja la terminación SSL, despliegues sin tiempo de inactividad y reinicios progresivos sin servicios externos como Nginx o HAProxy.

Soporte Mejorado de SQLite para Producción

Rails 8 mejora el soporte de SQLite para uso en producción. El pooling de conexiones, el modo WAL y una concurrencia mejorada hacen que SQLite sea viable para aplicaciones de tamaño pequeño a mediano. Combinado con el Solid Trifecta, una aplicación Rails 8 en un solo servidor puede funcionar completamente con SQLite sin un servidor de base de datos externo.

# config/database.yml (configuración de SQLite en producción)
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

Esta configuración ejecuta toda la stack de la aplicación desde cuatro archivos SQLite. Kamal monta el directorio de almacenamiento como un volumen persistente, asegurando la supervivencia de los datos durante los reinicios de contenedores.

Actualización de Rails 7 a Rails 8

La ruta de migración de Rails 7.2 a Rails 8.0 es directa si la aplicación ya maneja las advertencias de deprecación. Las aplicaciones en Rails 7.0 o 7.1 deben actualizarse de forma incremental: 7.0 a 7.1, luego 7.2, luego 8.0.

Paso 1: Actualizar las Dependencias

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

bundle update rails

Paso 2: Ejecutar la Tarea de Actualización

bin/rails app:update

Este comando actualiza los archivos de configuración a los valores por defecto de Rails 8. Se recomienda revisar cada cambio cuidadosamente usando git diff. Los cambios clave incluyen el nuevo valor por defecto de Regexp.timeout (1 segundo), el comportamiento actualizado de db:migrate (carga de esquema en bases de datos nuevas) y la configuración de Propshaft.

Paso 3: Manejar la Reordenación del Esquema

Rails 8 reordena las columnas de schema.rb para coincidir con el orden real de las columnas en la base de datos. Se recomienda ejecutar el dump del esquema inmediatamente para aislar este diff cosmético de los cambios reales de migración:

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

Paso 4: Adoptar las Nuevas Características de Forma Incremental

El Solid Trifecta, Propshaft y el generador de autenticación son opcionales para las aplicaciones existentes. La adopción se realiza individualmente una vez que la actualización principal sea estable:

1. Reemplazar el adaptador de tareas con Solid Queue
2. Cambiar el cache store a Solid Cache
3. Migrar Action Cable a Solid Cable (si corresponde)
4. Evaluar la migración a Propshaft para el pipeline de assets

Paso 5: Actualizar el Manejo de Parámetros

Reemplazar las llamadas params.require.permit con params.expect en los controladores. Este cambio es opcional pero recomendado para una validación de parámetros más estricta.

Rails 8.1: Tareas Continuables y CI Integrado

Rails 8.1, lanzado en octubre de 2025, se construye sobre las bases de Rails 8 con dos características principales. Las tareas continuables (ActiveJob::Continuable) dividen las tareas de larga duración en pasos reanudables. Si un servidor se reinicia durante una importación, la tarea retoma exactamente donde se detuvo en lugar de comenzar desde cero.

# 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 también introduce configuración de CI integrada y renderizado nativo de Markdown, reduciendo aún más las dependencias externas.

Conclusión

• El Solid Trifecta (Queue, Cache, Cable) elimina Redis como dependencia obligatoria para tareas en segundo plano, caché y WebSockets
• El generador de autenticación integrado proporciona una base para la autenticación basada en sesiones sin gemas de terceros
• params.expect reemplaza params.require.permit con un manejo de parámetros más estricto y seguro
• Propshaft reemplaza Sprockets como pipeline de assets por defecto, delegando el bundling a herramientas modernas
• Kamal 2 y Thruster ofrecen despliegue sin tiempo de inactividad sin Nginx ni Capistrano
• La actualización desde Rails 7.2 es incremental: actualizar dependencias, ejecutar app:update, adoptar nuevas características una por una
• Rails 8.1 agrega tareas continuables y CI integrado para equipos que buscan reducir herramientas externas