Un entorno de vista previa por pull request, en servidores que posees tú
Los entornos de vista previa por PR son una de esas funciones que, en retrospectiva, hicieron que el flujo de Vercel y Netlify se sintiera inevitable: un revisor hace clic en un link en vez de leer un diff e imaginarse qué hace. Lo que es fácil pasar por alto cuando ese flujo solo existe en la plataforma administrada de otro: cada uno de esos entornos de vista previa es un servidor corriendo, y los servidores corriendo cuestan dinero, mire alguien el PR o no.
Qué hace realmente activar esto
Con GitHub conectado, activas los previews para una app y cada pull request a partir de ese momento recibe su propia copia completa: el mismo build, los mismos tipos de proceso, su propia URL, eliminada automáticamente en el instante en que el PR se cierra. No hay que aprovisionar nada a mano por cada PR, ni limpiar nada cuando termina; el ciclo de vida coincide exactamente con el del propio PR.
La parte que de verdad es distinta: los previews se duermen
Este es el detalle que importa más que el mecanismo de preview en sí: las apps nuevas de staging y de preview se duermen por defecto tras 30 minutos sin tráfico, y el siguiente request las despierta. Un PR que queda abierto dos semanas mientras alguien está de vacaciones no es un servidor andando al costo completo esas dos semanas: es un servidor dormido casi todo el tiempo, que despierta en el instante en que alguien vuelve a abrir el link del preview.
Configurable por app en Settings → General: nunca, 10 minutos, 30 minutos, 1 hora, 6 horas o un día entero sin tráfico antes de dormir — o define horas despierto en su lugar: días específicos y una ventana horaria (en la zona horaria propia de la app) en la que debe seguir activa, durmiendo fuera de esa ventana sin importar el tráfico y despertando con el siguiente request en cualquier caso.
railyard sleep my-preview-app 30Entornos completos, no solo previews
Los previews son el caso acotado a un PR de una idea más amplia: los entornos son copias completas de un proyecto —producción, staging, lo que un equipo necesite— creadas desde el canvas. Los servicios dentro de un mismo entorno se referencian entre sí de la forma normal (${{api.RAILYARD_PRIVATE_URL}}), resuelta dentro de ese mismo entorno automáticamente, así que los servicios de un entorno de staging hablan con la base de datos propia de staging, no con la de producción, sin que nada tenga que saber a mano la diferencia.
Por qué el modelo de costos es el verdadero punto
Un sistema de preview por PR que cobra como un servidor de producción por cada PR abierto, o se usa con cuentagotas (lo que anula el sentido de tenerlo) o se vuelve una línea de gasto que alguien termina cuestionando. Uno que se duerme por defecto hace lo útil (un entorno en ejecución al que de verdad puedes entrar a probar) sin la contrapartida habitual de pagar precio completo por infraestructura inactiva la mayor parte de la vida de un PR.
Referencia completa: Entornos y previews.