Um ambiente de preview por pull request, em servidores que são seus
Ambientes de preview por PR são uma daquelas funcionalidades que, em retrospecto, fizeram o workflow da Vercel e da Netlify parecer inevitável — um revisor clica num link em vez de ler um diff e imaginar o que ele faz. A parte fácil de esquecer quando esse workflow só existe na plataforma gerenciada de outra pessoa: cada um desses ambientes de preview é um servidor rodando, e servidores rodando custam dinheiro, alguém olhando o PR ou não.
O que ativar isso realmente faz
Com o GitHub conectado, ative os previews pra uma aplicação e todo pull request depois disso recebe a própria cópia completa — mesmo build, mesmos tipos de processo, a própria URL, removida automaticamente no momento em que o PR fecha. Sem provisionamento manual por PR, sem limpeza manual quando termina; o ciclo de vida acompanha exatamente o ciclo de vida do próprio PR.
A parte que é realmente diferente: os previews dormem
Esse é o detalhe que importa mais do que o próprio mecanismo de preview: aplicações novas de staging e preview dormem por padrão depois de 30 minutos sem tráfego, e a próxima requisição as desperta de novo. Um PR que fica aberto por duas semanas enquanto alguém está de férias não é um servidor ocioso custando o preço cheio por duas semanas — é um servidor que está dormindo quase o tempo todo e desperta no momento em que alguém de fato abre o link do preview de novo.
Configurável por aplicação em Settings → General: nunca, 10 minutos, 30 minutos, 1 hora, 6 horas, ou um dia inteiro sem tráfego antes de dormir — ou defina horários ativos em vez disso, dias específicos e uma janela de horário (no fuso horário da própria aplicação) em que ela deve ficar de pé, dormindo fora dessa janela independentemente do tráfego e despertando na próxima requisição de qualquer jeito.
railyard sleep my-preview-app 30Ambientes completos, não só previews
Previews são o caso restrito a PR de uma ideia mais ampla: ambientes são cópias completas de um projeto — produção, staging, o que quer que uma equipe precise — criadas a partir do canvas. Serviços dentro de um mesmo ambiente se referenciam do jeito normal (${{api.RAILYARD_PRIVATE_URL}}), resolvido dentro desse mesmo ambiente automaticamente, então os serviços de um ambiente de staging falam com o próprio banco de dados do staging, não o de produção, sem nada fixado no código pra saber a diferença.
Por que o modelo de custo é o ponto de verdade
Um sistema de preview por PR que cobra como um servidor de produção pra cada PR aberto ou é usado com moderação (o que anula o propósito de ter isso) ou se transforma numa linha de custo que alguém eventualmente questiona. Um que dorme por padrão faz a coisa útil (um ambiente rodando pra você de fato clicar e navegar) sem a troca usual de pagar o preço cheio por infraestrutura ociosa na maior parte da vida de um PR.
Referência completa: Environments and previews.