Lo que lanzamos, del más reciente al más antiguo.

railyard apps:rm <app> elimina una app desde el CLI, pero solo con --confirm <app-name> coincidiendo con el nombre propio de la app —el mismo patrón de confirmación escrita que el panel ya usa para acciones destructivas, así un despliegue automatizado no puede eliminar por accidente la app equivocada por un error de tipeo.

Corrimos una pasada de verificación en vivo sobre decenas de plantillas de apps de la comunidad —Immich, Affine, MediaCMS, Supabase, Dify, Appwrite, LibreChat, Seafile, Rocket.Chat, PostHog, LogChimp, Castopod, Zulip, Airbyte, Langfuse y otras— y arreglamos lo que un despliegue real realmente dejó ver: variables de entorno faltantes, puertos por defecto equivocados, y un puñado de colisiones de llave de lanzamiento donde dos plantillas compartían el mismo identificador.

Misma pasada, tres arreglos a nivel de plataforma que nunca fueron visibles en el día a día pero que hacen más probable que un servidor se recupere solo en silencio en vez de necesitar un empujón manual: un servidor que conectaba almacenamiento en una ruta de dispositivo inesperada, un watchdog de enrutamiento que reiniciaba con demasiadas ganas, y un cambio de DNS cuyos dependientes no siempre lo detectaban. Explora el catálogo de plantillas.

Ahora cualquiera puede crear una cuenta sin invitación. Los equipos nuevos arrancan en el plan Free (1 servidor, 3 apps) con 14 días de Pro, sin tarjeta. Pro y Team son precios planos por equipo sin facturación por uso; los equipos que se unieron antes de hoy mantienen Pro gratis. Precios, Documentación.

Una revisión de seguridad independiente llevó a un alcance más acotado de los tokens de API, comprobaciones más estrictas sobre requests salientes y hostnames, y sin previews para pull requests desde forks. También corregimos varios problemas menores en la creación de apps, las actualizaciones de estado de despliegue y las páginas públicas.

El proxy frente a cada app ahora maneja lo que de otra forma configurarías en Nginx, desde Settings → Networking de una app:

• Redirecciones y rewrites, opcionalmente limitadas a un solo host.
• Headers de respuesta y CORS, con requests preflight respondidos en el borde.
• Páginas de error y mantenimiento personalizadas.
• Enrutamiento por ruta para servir una app bajo una ruta de otra.
• Tus propios certificados TLS, validados al subirlos y almacenados cifrados.
• Verificación de dominio con un registro TXT antes de que Railyard enrute un dominio o emita un certificado, y dominios wildcard en un solo certificado.
• Límites de tasa y bloqueo por país (beta).

Mira Reglas de borde y Dominios.

• Los despliegues canarios envían una parte del tráfico a un release nuevo, en un paso o en varios (por ejemplo 5%, 25%, y después 50%). La página del despliegue compara su tasa de errores y latencia con el release actual, y Railyard puede promover o revertir por su cuenta.
• Ventanas de despliegue y despliegues programados. Los pushes fuera de la ventana de una app esperan hasta que se abra.
• Notas de despliegue en despliegues manuales y rollbacks, y rollbacks que restauran las variables con las que corría un release.
• Apps en varios servidores, con balanceo de carga con comprobación de salud y vaciado al quitarlas.
• Failover automático redespliega una app en otro servidor, preferiblemente en otra región, cuando su servidor deja de responder, promueve el standby de la base de datos y actualiza el DNS.
• Red privada entre servidores sobre una malla WireGuard cifrada.

Mira Despliegues canarios y ventanas de despliegue y Autoescalado y failover.

• El CLI es un solo binario para macOS y Linux, instalado con Homebrew o un script de una línea. railyard login inicia sesión con un código confirmado en el panel, y railyard upgrade lo actualiza en el lugar.
• git push railyard main despliega exactamente ese commit y transmite el log de vuelta a tu terminal, sin necesitar GitHub. Los pushes son estrictos por defecto: un build fallido rechaza el push.
• railyard tunnel reenvía un puerto local a una app o su base de datos sin abrir un puerto, y railyard deploy --local construye con tu propio Docker.
• Un provider de Terraform para apps, variables y dominios.
• Las apps de imagen siguen su tag, redesplegando cuando Docker Hub, GHCR, Quay o un registro privado publica un digest nuevo.

Mira CLI y Terraform.

• Los servidores de base de datos solo guardan datos: sin proxy, sin builds, y puertos abiertos únicamente a los servidores de app que los usan. Las apps existentes pueden mover sus datos con fallback automático si la copia falla.
• Standbys que transmiten desde el primario y se pueden promover desde la página de cualquiera de los dos servidores.
• Recuperación a un punto en el tiempo a cualquier segundo de los últimos siete días, desde el WAL archivado en tu almacén de backups. Los servidores de base de datos nuevos corren Postgres 17.
• PgBouncer por servidor, con DATABASE_DIRECT_URL conservado para migraciones.
• Actualizaciones mayores de Postgres (beta) con una comprobación de compatibilidad, un backup primero y siete días para revertir.
• Forks de base de datos para staging y previews, con un script de enmascarado opcional que corre antes de que nadie pueda conectarse.
• Consolas, exportación e importación para cada complemento, un explorador de archivos para almacenamiento de objetos, y la opción de mantener el almacenamiento de objetos en tu propia cuenta de AWS.

Mira Servidores de base de datos.

• Snapshots en DigitalOcean, Hetzner, Vultr y AWS, tomados automáticamente antes de cada cambio de tamaño.
• Actualizaciones de sistema operativo con conteos de pendientes y de seguridad, avisos de fin de soporte, instalación con un clic y actualizaciones de seguridad nocturnas opcionales.
• ActiveProtect bloquea IPs que sondean rutas como /.env o /wp-login.php, y fail2ban detiene la fuerza bruta por SSH. Los servidores cambian a SSH solo por clave en cuanto se instala una.
• Almacenamiento de base de datos cifrado en un volumen LUKS, y discos cifrados en los servidores nuevos de AWS.
• Un firewall de aplicación web (OWASP Core Rule Set) por app en modo detección o bloqueo, más aislamiento reforzado opcional y sistemas de archivos de solo lectura para contenedores.
• Detección de secretos avisa cuando un repositorio hace commit de credenciales como archivos .env o claves privadas.

Mira Mantenimiento del servidor.

• El canvas es un mapa en vivo de un proyecto: sus servicios, bases de datos y las conexiones entre ellos. Cambia de entorno, haz fork de un proyecto, y mira qué servicio tiene abierto cada compañero de equipo. Los servicios se alcanzan entre sí en <app>.railyard.internal y referencian las variables de los demás con ${{service.VAR}}.
• Sitios estáticos y funciones se pueden crear desde el canvas.
• Plantillas. Alrededor de 200 apps open-source están en un catálogo público, y cualquier proyecto se puede publicar como plantilla. Los secretos nunca se publican; se piden o se generan al momento del despliegue.
• Botón Deploy to Railyard para READMEs, que abre una configuración precargada en el propio servidor del visitante.
• Proxy TCP para llegar a una base de datos desde afuera, activado y desactivado desde su panel.

Mira El canvas y Botón de despliegue.

• Sleep después del tiempo de inactividad que elijas, y despertar en el siguiente request. Las apps de staging y preview se duermen por defecto tras 30 minutos inactivos, las horas despierto mantienen una app arriba solo durante los horarios que definas, y las apps que solo tienen worker despiertan según un horario para vaciar sus colas.
• Autoescalado de réplicas web entre un piso y un techo según latencia p95 o CPU, con ventanas programadas que agregan capacidad antes de un pico conocido.
• Importa desde Heroku, Render, Fly.io y Railway con un token de API: procesos, variables, bases de datos con sus datos, y dominios. Los importadores de Heroku, Render y Fly.io están en beta.
• Costs lee tu factura de nube real, encuentra servidores, discos e IPs sin usar, y alerta al 50%, 80% y 100% de un presupuesto mensual. Un límite estricto opcional duerme las apps que no son de producción y bloquea servidores nuevos.
• Páginas de estado públicas con disponibilidad de 90 días.

Mira Costos y ahorros e Importar desde otra plataforma.

Las apps de Rails se detectan al crearlas. Los workers se encuentran en el repositorio, los assets se construyen con Propshaft, importmap, jsbundling o cssbundling, Active Storage recibe un volumen persistente, y cada base de datos en database.yml se crea, así que Solid Queue, Solid Cache y Solid Cable funcionan en Rails 8 sin configuración.

Las apps de Laravel con laravel/octane corren bajo Octane sobre FrankenPHP, y las apps con laravel/reverb reciben un worker de Reverb. Symfony y WordPress también se construyen sin Dockerfile.

Mira Rails y Laravel.

• Inicio de sesión único por OpenID Connect o SAML 2.0, con Google Workspace, Okta, Microsoft Entra, OneLogin y otros. Los dominios se verifican con un registro DNS, los miembros nuevos se unen en su primer inicio de sesión con el rol que elijas, y se puede exigir SSO para todos en tu dominio.
• SCIM 2.0 agrega y quita miembros desde tu proveedor de identidad.
• Puntaje de seguridad sobre 100 a partir de diez comprobaciones, incluyendo cobertura de autenticación en dos pasos, parches de sistema operativo pendientes, puertos abiertos, certificados por vencer y backups sin verificar. Cada comprobación enlaza a su arreglo.
• Claves SSH del equipo instaladas en cada servidor que corre el equipo, y eliminadas en menos de un minuto cuando se va una clave o un miembro.
• Servidor MCP para agentes de IA. Claude Code, Cursor y otros clientes MCP usan los mismos tokens de API que el CLI. Las acciones destructivas se convierten en solicitudes que un admin aprueba primero.
• Configuración de cuenta: cambia tu correo y contraseña, exporta tus datos como JSON, o elimina tu cuenta.

Mira Equipos y SSO y MCP.

• Servidores de build. Dale a un servidor el rol de builder y se encarga de compilar, así un build pesado nunca compite con el tráfico en vivo en tus servidores de app.
• Rebuilds más rápidos gracias a una caché de build compartida, y un límite de memoria para que un build grande falle de forma limpia en vez de agotar el servidor.
• Los builds se recuperan de fallas comunes: imágenes base desactualizadas, builds viejos de webpack, Node quedándose sin memoria, casos límite de empaquetado en Python y restricciones de versión de PHP. Cuando un Dockerfile sigue fallando, Railyard reintenta con Railpack usando las versiones fijadas en tu código.
• Repositorios multi-servicio. Un archivo compose o un repositorio con varios Dockerfiles ofrece crear todos los servicios a la vez, con los almacenes de datos que necesitan.

• Alertas de métricas sobre latencia p95, tasa de 5xx, memoria o CPU, revisadas cada minuto, con un seguimiento cuando las cosas se recuperan.
• Access logs: cada request a través del proxy se registra con método, ruta, estado, duración y cliente, y se puede buscar junto con los logs de tu app.
• OpenTelemetry: dale a una app un endpoint OTLP y Railyard configura las variables estándar OTEL_* y envía sus propias métricas de CPU, memoria y requests al mismo lugar.
• Vista de la cola de jobs (beta) para Sidekiq, Solid Queue, GoodJob, Resque y Delayed Job, con retry, discard y una alerta de backlog.
• Retención de logs por equipo, con búsqueda en cualquier rango de fechas y descarga en texto plano.

Mira Logs, métricas y alertas.

• Un despliegue termina cuando los usuarios pueden llegar a él, no cuando arranca el contenedor. Railyard revisa la app en su URL real de HTTPS antes de mover el tráfico, y una redirección sola ya no pasa como app sana.
• Los crash loops se pausan. Un proceso que sigue cayéndose por diez minutos se detiene en vez de reiniciarse para siempre, y la página de la app muestra por qué se cayó. Restart lo arranca de nuevo.
• Progreso en vivo para trabajos largos. Crear un servidor, backups, restauraciones, importaciones y cambios de tamaño muestran sus pasos, la salida reciente y el tiempo restante, y siguen corriendo si sales de la página.

Los repositorios sin Dockerfile ahora se construyen automáticamente con Cloud Native Buildpacks, usando capas de runtime prearmadas en vez de compilar un lenguaje desde el código fuente. Tu repositorio se lee de la misma forma en que lo lee Heroku, así que una app que se muda normalmente no necesita cambios.

Un Procfile declara los tipos de proceso y el comando de release. Los procesos web y worker arrancan desde ahí, y la entrada release: corre antes de que la versión nueva reciba tráfico.

Mira Métodos de build.

• Conecta GitHub instalando la Railyard GitHub App una sola vez, y después elige repositorios de una lista. Los repositorios privados se clonan con tokens de corta duración, los pushes despliegan, y los commits reciben un status check.
• Conecta GitLab, en gitlab.com o self-managed, con un token de acceso en Team → Git providers.
• Entornos de vista previa para cada pull request y merge request, eliminados cuando se cierra. Los entornos de staging se pueden promover a producción.
• Cada despliegue fallido se explica solo: la causa probable, el arreglo, y la línea del log que lo demuestra, en la página del despliegue, el panel y el canvas.

Mira Conectar GitHub y Entornos y previews.

• Equipos con roles de propietario, admin, desarrollador y lector, y miembros que se pueden limitar a apps específicas.
• Inicio de sesión en dos pasos con cualquier app de autenticación, más códigos de respaldo.
• Una API REST con tokens acotados por equipo, y un cliente de línea de comandos construido sobre ella.
• Notificaciones para despliegues, servidores fuera de línea y crash loops, enviadas a Slack, un webhook o correo.
• Aprobaciones de despliegue: los despliegues de producción pueden esperar a que un admin los apruebe.
• Registro de actividad de cada despliegue, cambio de configuración y acción sobre un servidor.

• Crea un servidor en DigitalOcean, Hetzner, Vultr, AWS u OVHcloud desde el panel con tu propio token de API, o conecta cualquier servidor Linux por SSH. Railyard termina la configuración, configura el firewall y lo mantiene actualizado.
• Cada app recibe un hostname y un certificado TLS en cuanto se despliega. Agrega dominios personalizados, servidos directamente o redirigidos al principal, con el estado del certificado en la pestaña Domains.
• Jobs programados con historial de ejecuciones y Run now.
• Métricas del servidor con gráficos de CPU, memoria y disco, y alertas cuando un disco se llena o el uso se mantiene alto.
• Modo de mantenimiento por app.

Mira Agregar un servidor.

Agrega un almacén de datos a una app y Railyard lo corre en el mismo servidor, crea credenciales solo para esa app y define las variables de conexión en el siguiente despliegue.

• Postgres (con pgvector), MySQL, Redis, MongoDB, Elasticsearch, Memcached, RabbitMQ, InfluxDB y almacenamiento de objetos compatible con S3.
• Backups con un horario y una retención que eliges, restauración con un clic, y un verificador que restaura cada backup en una base de datos de prueba para comprobar que funciona.
• Volúmenes persistentes para apps que escriben a disco, con sus propios backups.

Mira Bases de datos y backups.

Railyard despliega un repositorio de Git en un servidor que posees tú: clona el código, lo construye y transmite el log del build a tu navegador mientras corre.

• Releases sin downtime. La versión nueva arranca junto a la vieja y solo recibe tráfico una vez que pasa una comprobación de disponibilidad. Una comprobación fallida deja a la versión vieja sirviendo.
• Procesos web y worker, cada uno con su propio comando y cantidad de réplicas, más un comando de release que corre antes de que se mueva el tráfico.
• Variables de entorno, cifradas en reposo y editables una a la vez o pegadas como un bloque .env.
• Rollback a cualquier release anterior con un clic.
• Fuentes privadas: clones autenticados con token, submódulos, argumentos de build, secretos de build, e imágenes prearmadas desde un registro privado.