Ruby · 3.3
Hosting Ruby 24/7
Sube una API Sinatra, un worker de cola o una automatización en Ruby y déjala corriendo. Las dependencias se instalan cuando se construye la imagen, el proceso arranca en un contenedor aislado y vuelve solo cuando cae.
Quién diseñó Ruby
Yukihiro Matsumoto empezó Ruby en 1993, insatisfecho con Perl y Python para lo que quería escribir. Publicó en 1995 un lenguaje que mezclaba la orientación a objetos de Smalltalk, la expresividad de Perl y bloques en la gramática — el criterio explícito era el placer de quien programa. La 1.0 llegó en 1996. Matz repetía que optimizaba para humanos, no para el compilador: la sintaxis debería sorprender poco.
Yukihiro Matsumoto
Mathias Meyer · CC BY-SA 2.0
Hecha para quien escribe
Matz diseñó Ruby para ser placentero, no para el compilador. La diferencia que quería de Perl y Python era esa: la sintaxis debería sorprender poco y caber en la cabeza.
Todo es objeto
Número, clase, nil. No hay tipo primitivo al margen. Es orientación a objetos sin la excepción que Java y C cargan en el núcleo.
Bloques en la lengua
Iteración y recurso no son un callback de biblioteca: el bloque es gramática. Es el modo Ruby de pasar comportamiento, no un extra de la API.
Lo que la plataforma hace por un proyecto Ruby
Lo esencial ya viene configurado en toda aplicación Ruby aquí; las funciones que dependen del plan se indican en la tarjeta.
Tres versiones, una línea de configuración
La 3.3 es la recomendada, la 3.4 es la más reciente y la 3.2 sigue disponible. Cambiar es modificar VERSION en el vertracloud.config y desplegar de nuevo — no hay imagen que elegir ni Dockerfile que mantener.
Gemas instaladas en el build
La instalación ocurre cuando se construye la imagen, no en cada arranque. El contenedor sube con todo listo y un fallo de instalación aparece en el log del build en vez de convertirse en una caída en producción. El build tiene 5 minutos.
Auto-reinicio con freno
Una excepción sin tratar no tumba el servicio: el proceso vuelve solo, en cualquier plan. Si se rompe 5 veces en 10 minutos, la plataforma marca crash loop y apaga el auto-reinicio durante 24 horas. Salir con exit code 0 no dispara reinicio.
Hoy en segundo plano, mañana en la web
Un worker arranca sin puerto HTTP. Si más adelante tiene que responder en internet, basta con publicar la aplicación: recibe subdominio y TLS. Activarlo y desactivarlo recrean el contenedor, así que el proceso se reinicia en ese momento.
Lo que la gente ejecuta en Ruby aquí
La automatización que se mantiene en pie durante semanas, y el servicio HTTP que el equipo publica cuando hace falta.
APIs Sinatra y Rack
Servicio HTTP publicado en un subdominio vertraweb.app. Enlaza el servidor en 0.0.0.0 y en el puerto 80 — lo que escucha en localhost no recibe tráfico externo y el sitio responde con timeout.
Workers y trabajos de cola
Consumidor de cola, rutina de ETL, tarea periódica: proceso largo que solo tiene que mantenerse en pie. El auto-reinicio cubre la caída ocasional sin que nadie se despierte para reiniciarlo.
Bots e integraciones
Automatización que queda conectada todo el tiempo, sin puerto expuesto. El token va en las variables de entorno del panel, nunca dentro del zip.
Ruby con base de datos gestionada
Crea un PostgreSQL 17, MySQL 8.0, MongoDB 8.0.11 o Redis 7 en el mismo panel y conecta por el host interno. TLS es obligatorio; el certificado y la contraseña los genera la plataforma y se pueden descargar.
Versiones de Ruby disponibles
La 3.3 es la recomendada, la 3.4 es la más reciente y la 3.2 sigue disponible. Para salir de la recomendada, declara VERSION en el vertracloud.config.
| Versión | vertracloud.config | Estado |
|---|---|---|
| 3.4 | VERSION=3.4 | Más reciente |
| 3.3 | VERSION=3.3 | Recomendada |
| 3.2 | VERSION=3.2 |
Toda la configuración
El vertracloud.config es un archivo INI opcional en la raíz del proyecto. MAIN apunta al archivo de entrada; VERSION elige el Ruby; MEMORY define el tope de RAM del contenedor.
NAME=meu-app
MAIN=app.rb
VERSION=3.3
MEMORY=512Un plan para cada etapa del proyecto
La memoria y el almacenamiento cambian según el plan; el lenguaje, no. Compara lo que abre cada plan y elige el que le sirve al proyecto hoy.
Comparar planesTambién corre aquí
Misma plataforma, mismo deploy, otro stack.
Preguntas frecuentes sobre hosting Ruby
Gemas, build y variables: lo que soporte más responde sobre Ruby.
¿Qué versiones de Ruby puedo usar?
3.3 (recomendada), 3.4 (la más reciente) y 3.2. La elección se hace con la clave VERSION del vertracloud.config; sin ella, la aplicación arranca con la recomendada.
¿Las gemas tienen que ir dentro del zip?
No — deja vendor/ fuera del paquete. Las gemas se instalan en el servidor durante el build, para Linux, y el zip acepta como máximo 100 MB.
Mi app arranca y se detiene enseguida. ¿Por qué?
Si el proceso termina con exit code 0, la plataforma entiende que cerró con normalidad y no lo reinicia. Asegúrate de que el servidor está escuchando o de que el bot quedó conectado: un script que corre hasta el final y sale no se mantiene en pie.
¿Cómo llegan las variables de entorno al proceso?
Por la pestaña del panel: se inyectan en el contenedor al arrancar y quedan cifradas en reposo. Son hasta 25 variables, con clave de hasta 100 caracteres y valor de hasta 1.000. La plataforma no lee archivos .env.
¿Cuánto puede tardar el build?
Hasta 5 minutos. Si la instalación de las gemas se pasa de ese tiempo, el build falla — quita las dependencias que el proyecto no usa. El zip enviado también tiene un tope de 100 MB.
Sube tu proyecto Ruby hoy
Crea la cuenta, envía un zip o conecta el repositorio de GitHub y sigue la instalación de las gemas por la terminal del panel.
Crear cuenta