Hosting VPS para Rails

El hosting VPS para Ruby on Rails ejecuta tu app en un servidor con un disco que conserva los datos entre despliegues. Rails 8 se lanzó como "No PaaS Required", y sus valores predeterminados están pensados para esa configuración. En un VPS de GreenGeeks, el servidor ejecuta AlmaLinux 9 con cPanel. Instalas Ruby 3.3, ejecutas la app con Puma y dejas que Apache le pase las peticiones. Rails 8 guarda las tareas, la caché y los WebSockets en tu base de datos, así que no hay que ejecutar Redis. El equipo gestionado de GreenGeeks se ocupa del sistema operativo y del servidor, y tú de la app, sus gemas y sus despliegues.

Una app Rails 8 con SQLite cabe en el plan de 4 GB. Sus 4 vCPU ejecutan de 2 a 4 workers de Puma, con las tareas ejecutándose dentro de Puma. Rails usa por defecto 3 hilos por worker y recomienda un worker por núcleo. Un worker típico usa entre 400 y 600 MB, y algunas apps pesadas llegan a 1,8 GB por worker. Pasa a 8 GB con 6 vCPU cuando añadas MariaDB o des a las tareas su propio proceso. El plan de 16 GB añade memoria para workers más pesados, no más núcleos. Una app que necesite más de 6 workers necesita un segundo servidor.

No. Kamal instala Docker por SSH y ejecuta cada versión en un contenedor, y el VPS de GreenGeeks no admite Docker. Rails funciona bien sin él. Instala Ruby 3.3 desde los propios paquetes de AlmaLinux con dnf, ejecuta Puma bajo systemd y deja que Apache envíe el tráfico de tu dominio a él. En cada versión, ejecuta git pull, bundle install, db:migrate y assets:precompile, y después reinicia Puma. Capistrano puede ejecutar esos pasos desde tu propio ordenador. El Dockerfile y el config/deploy.yml que genera Rails 8 pueden quedarse en el repositorio sin usarse.

Empieza por los cuatro archivos SQLite de storage/. Copiar un archivo de base de datos en uso con cp puede dejarte una copia corrupta, así que respáldalos con VACUUM INTO o la API de copia de seguridad de SQLite, ejecutada como tarea recurrente en config/recurring.yml. Para MariaDB, ejecuta mysqldump de forma programada. GreenGeeks no hace copias de seguridad de los servidores VPS, así que activa las copias diarias de cPanel y envíalas a Amazon S3. Mantén la app dentro de la carpeta personal de una cuenta de cPanel para que esas copias la incluyan. Guarda config/master.key en un gestor de contraseñas, ya que sin él no se pueden leer tus credenciales cifradas.

Sí, siempre que el servidor conserve su disco entre despliegues, como hace un VPS. Rails 8 dejó SQLite listo para producción con los modos WAL e IMMEDIATE activados por defecto. Una app nueva guarda cuatro archivos SQLite en storage/: uno para los datos principales y uno para la cola, la caché y Action Cable. En el VPS de GreenGeeks esa carpeta está en el SSD, y ninguna versión la toca. 37signals ejecuta miles de instalaciones de Campfire y Writebook con SQLite. Encaja con una app que funciona en un solo servidor. Heroku no puede ejecutarlo, porque el disco de un dyno se borra al reiniciarse.

Rails 8.0 y 8.1 necesitan Ruby 3.2 o superior. La última versión, Rails 8.1.4, salió el 24 de septiembre de 2026. En AlmaLinux 9, instalas Ruby 3.3 desde el módulo AppStream con dnf, y YJIT se activa solo. Las gemas con código nativo necesitan gcc, make y ruby-devel, y el acceso root te permite instalarlos. En cuanto a la base de datos, SQLite funciona en el VPS de GreenGeeks, y también MariaDB 11.4 mediante el adaptador mysql2 o trilogy. PostgreSQL allí solo está en la versión 9.6, que llegó al final de su vida útil en 2021, así que MariaDB o SQLite encajan mejor.

Una app Rails en un VPS de GreenGeeks cuesta $69.95 al mes en el plan de 4 GB con 4 vCPU, $129.95 en el de 8 GB con 6 vCPU o $179.95 en el de 16 GB. Puma, Solid Queue y MariaDB comparten ese mismo servidor, así que una sola factura cubre la app web, las tareas en segundo plano y la base de datos. Una app con SQLite funciona bien con 4 GB. Una app con MariaDB y un proceso de tareas aparte cabe en 8 GB, y los workers pesados o una copia de staging caben en 16 GB. Además del plan, reserva presupuesto para almacenamiento externo para tus copias de seguridad.

Planifica primero el traslado de la base de datos. PostgreSQL en el VPS de GreenGeeks es la versión 9.6, así que la mayoría de las apps cambian a MariaDB 11.4 o SQLite. Cambia el adaptador en config/database.yml, ejecuta db:prepare para crear el esquema, copia tus datos y prueba la app con la nueva base de datos. Pon las config vars de Heroku en el archivo de servicio de Puma, junto con RAILS_MASTER_KEY. Cuando la app funcione en el nuevo servidor, apunta el registro A de tu dominio a la IP dedicada. Mantén la app de Heroku en marcha hasta que el cambio de DNS haya llegado a todos.

Tú te ocupas de Ruby, Rails, tus gemas y cada despliegue, y el equipo gestionado de GreenGeeks mantiene AlmaLinux y el servidor actualizados. Su ayuda cubre el servidor y cPanel, no la app. Los problemas de Rails más comunes durante el primer mes son un número de hilos incorrecto, assets que no se precompilaron y procesos web y de tareas que comparten un mismo pool de conexiones a la base de datos. WEB_CONCURRENCY=auto también puede leer mal el número de CPU en un servidor virtual, así que fija tú el número de workers. Después de cada despliegue, revisa los registros del servicio de Puma con journalctl para detectar pronto un arranque fallido.

Con la misma memoria, GreenGeeks cuesta menos que Heroku. A octubre de 2026, el dyno Performance-M de Heroku cuesta $250 al mes por 2,5 GB, y un worker en segundo plano necesita un segundo dyno además de ese. El plan de 4 GB de GreenGeeks cuesta $69.95 con 4 vCPU. Fly.io es más barato en tamaños pequeños, a $33 por una máquina performance-1x de 2 GB, pero su Postgres gestionado añade $38 al mes en el plan Basic. Los planes Essential Postgres de Heroku cuestan de $5 a $20. En GreenGeeks, MariaDB funciona en el mismo servidor sin coste adicional, y el equipo gestionado se encarga de los parches del sistema operativo.