O que foi lançado, do mais recente para o mais antigo.

railyard apps:rm <app> exclui um app a partir da CLI, mas só com --confirm <app-name> correspondendo ao próprio nome do app — o mesmo padrão de confirmação digitada que o dashboard já usa para ações destrutivas, para que um deploy automatizado não consiga apagar o app errado por acidente num erro de digitação.

Rodamos uma rodada de verificação ao vivo em dezenas de templates de apps da comunidade — Immich, Affine, MediaCMS, Supabase, Dify, Appwrite, LibreChat, Seafile, Rocket.Chat, PostHog, LogChimp, Castopod, Zulip, Airbyte, Langfuse e outros — e corrigimos o que um deploy real de fato revelou: variáveis de ambiente faltando, portas padrão erradas, e um punhado de colisões de chave de lançamento onde dois templates compartilhavam o mesmo identificador.

Na mesma rodada, três correções de nível de plataforma que nunca foram visíveis no dia a dia, mas tornam um servidor mais propenso a se curar silenciosamente por conta própria em vez de precisar de um empurrão manual: um servidor conectando armazenamento num caminho de dispositivo inesperado, um watchdog de roteamento que reiniciava com pressa demais, e uma mudança de DNS cujos dependentes nem sempre percebiam. Veja o catálogo de templates.

Qualquer pessoa agora pode se cadastrar sem convite. Equipes novas começam no plano Free (1 servidor, 3 apps) com 14 dias de Pro, sem cartão. Pro e Team são preços fixos por equipe, sem cobrança por uso; equipes que entraram antes de hoje mantêm o Pro de graça. Pricing, Docs.

Uma revisão de segurança independente levou a um escopo mais restrito dos tokens de API, verificações mais estritas em requisições de saída e hostnames, e nenhum preview para pull requests vindas de forks. Também corrigimos uma série de problemas menores na criação de apps, nas atualizações de status de deploy e nas páginas públicas.

O proxy na frente de todo app agora cuida do que você de outra forma configuraria no Nginx, a partir de Settings → Networking de um app:

• Redirecionamentos e rewrites, opcionalmente limitados a um único host.
• Cabeçalhos de resposta e CORS, com requisições preflight respondidas no edge.
• Páginas de erro e manutenção personalizadas.
• Roteamento por caminho para servir um app sob um caminho de outro.
• Seus próprios certificados TLS, validados no upload e guardados criptografados.
• Verificação de domínio com um registro TXT antes de o Railyard rotear um domínio ou emitir um certificado, e domínios wildcard num único certificado.
• Limites de taxa e bloqueio por país (beta).

Veja Edge rules e Domains.

• Canary deploys enviam uma fração do tráfego para uma nova release, numa etapa ou várias (por exemplo 5%, 25%, depois 50%). A página do deploy compara a taxa de erro e a latência dela com a release atual, e o Railyard pode promover ou fazer rollback por conta própria.
• Janelas de deploy e deploys agendados. Pushes fora da janela de um app esperam até ela abrir.
• Notas de deploy em deploys manuais e rollbacks, e rollbacks que restauram as variáveis com as quais uma release rodou.
• Apps em vários servidores, com balanceamento de carga verificado por health check e drenagem na remoção.
• Failover automático refaz o deploy de um app em outro servidor, preferencialmente em outra região, quando o servidor dele para de responder, promove o standby do banco de dados e atualiza o DNS.
• Rede privada entre servidores por uma malha WireGuard criptografada.

Veja Canary deploys and deploy windows e Scaling and failover.

• A CLI é um binário único para macOS e Linux, instalado com Homebrew ou um script de uma linha. railyard login entra com um código confirmado no dashboard, e railyard upgrade atualiza ela no lugar.
• git push railyard main faz o deploy daquele commit exato e transmite o log de volta para o seu terminal, sem precisar do GitHub. Pushes são estritos por padrão: uma build que falha rejeita o push.
• railyard tunnel encaminha uma porta local para um app ou seu banco de dados sem abrir uma porta, e railyard deploy --local constrói com o seu próprio Docker.
• Um provider do Terraform para apps, variáveis e domínios.
• Apps de imagem acompanham sua tag, refazendo o deploy quando o Docker Hub, GHCR, Quay ou um registro privado publica um novo digest.

Veja CLI e Terraform.

• Servidores de banco de dados guardam só dados: sem proxy, sem builds, e portas abertas só para os servidores de app que os usam. Apps existentes podem mover seus dados para lá com fallback automático se a cópia falhar.
• Standbys que transmitem a partir do primário e podem ser promovidos a partir da página de qualquer um dos dois servidores.
• Recuperação num ponto no tempo para qualquer segundo dos últimos sete dias, a partir de WAL arquivado no seu repositório de backup. Novos servidores de banco de dados rodam Postgres 17.
• PgBouncer por servidor, com DATABASE_DIRECT_URL mantida para migrações.
• Upgrades de versão maior do Postgres (beta) com uma verificação de compatibilidade, um backup primeiro e sete dias para fazer rollback.
• Forks de banco de dados para staging e previews, com um script de mascaramento opcional que roda antes de qualquer um conseguir conectar.
• Consoles, exportação e importação para todo add-on, um navegador de arquivos para object storage, e a opção de manter o object storage na sua própria conta AWS.

Veja Database servers.

• Snapshots na DigitalOcean, Hetzner, Vultr e AWS, tirados automaticamente antes de cada redimensionamento.
• Atualizações de SO com contagens pendentes e de segurança, avisos de fim de vida, instalação com um clique e atualizações de segurança noturnas opcionais.
• ActiveProtect bane IPs que sondam caminhos como /.env ou /wp-login.php, e o fail2ban bloqueia força bruta de SSH. Servidores trocam para SSH só com chave assim que uma chave é instalada.
• Armazenamento de banco de dados criptografado num volume LUKS, e discos criptografados em novos servidores AWS.
• Um firewall de aplicação web (OWASP Core Rule Set) por app em modo de detecção ou bloqueio, mais isolamento reforçado opcional e sistemas de arquivos somente leitura para containers.
• Detecção de segredos avisa quando um repositório comita credenciais como arquivos .env ou chaves privadas.

Veja Server maintenance.

• O canvas é um mapa em tempo real de um projeto: seus serviços, bancos de dados e as conexões entre eles. Troque de ambiente, dê fork num projeto, e veja qual serviço cada colega de equipe tem aberto. Serviços se alcançam em <app>.railyard.internal e referenciam as variáveis um do outro com ${{service.VAR}}.
• Sites estáticos e functions podem ser criados a partir do canvas.
• Templates. Cerca de 200 apps open-source estão num catálogo público, e qualquer projeto pode ser publicado como template. Segredos nunca são publicados; eles são pedidos ou gerados no momento do deploy.
• Botão Deploy to Railyard para READMEs, que abre uma configuração pré-preenchida no próprio servidor do visitante.
• Proxy TCP para acessar um banco de dados de fora, ativado e desativado no painel dele.

Veja The canvas e Deploy button.

• Sleep depois do tempo ocioso que você escolher e acorda na próxima requisição. Apps de staging e preview dormem depois de 30 minutos ociosos por padrão, horas despertas mantêm um app no ar só nos horários que você definir, e apps só de worker acordam na agenda para esvaziar suas filas.
• Autoscaling de réplicas web entre um piso e um teto baseado em latência p95 ou CPU, com janelas agendadas que adicionam capacidade antes de um pico conhecido.
• Importação do Heroku, Render, Fly.io e Railway com um token de API: processos, variáveis, bancos de dados com seus dados, e domínios. Os importadores de Heroku, Render e Fly.io estão em beta.
• Costs lê sua conta de nuvem real, encontra servidores, discos e IPs não usados, e alerta em 50%, 80% e 100% de um orçamento mensal. Um limite rígido opcional coloca apps de não produção para dormir e bloqueia novos servidores.
• Status pages públicas com uptime de 90 dias.

Veja Costs and savings e Import from another platform.

Apps Rails são detectados na criação. Workers são encontrados no repositório, assets são construídos com Propshaft, importmap, jsbundling ou cssbundling, o Active Storage recebe um volume persistente, e todo banco de dados no database.yml é criado, então Solid Queue, Solid Cache e Solid Cable funcionam no Rails 8 sem configuração.

Apps Laravel com laravel/octane rodam sob o Octane no FrankenPHP, e apps com laravel/reverb recebem um worker Reverb. Symfony e WordPress também constroem sem Dockerfile.

Veja Rails e Laravel.

• Single sign-on via OpenID Connect ou SAML 2.0, com Google Workspace, Okta, Microsoft Entra, OneLogin e outros. Domínios são verificados com um registro de DNS, novos membros entram no primeiro login com o papel que você escolher, e o SSO pode ser exigido para todo mundo no seu domínio.
• SCIM 2.0 adiciona e remove membros a partir do seu provedor de identidade.
• Score de segurança de até 100 a partir de dez verificações, incluindo cobertura de dois fatores, patches de SO pendentes, portas abertas, certificados expirando e backups não verificados. Cada verificação leva à sua correção.
• Chaves SSH de equipe instaladas em todo servidor que a equipe roda, e removidas em menos de um minuto quando uma chave ou membro sai.
• Servidor MCP para agentes de IA. Claude Code, Cursor e outros clientes MCP usam os mesmos tokens de API que a CLI. Ações destrutivas se tornam pedidos que um admin aprova primeiro.
• Configurações de conta: troque seu e-mail e senha, exporte seus dados como JSON, ou exclua sua conta.

Veja Teams and SSO e MCP.

• Servidores de build. Dê a um servidor o papel de builder e ele assume a compilação, então uma build pesada nunca compete com o tráfego real nos seus servidores de app.
• Rebuilds mais rápidos a partir de um cache de build compartilhado, e um limite de memória para que uma build grande falhe de forma limpa em vez de esgotar o servidor.
• Builds se recuperam de falhas comuns: imagens base desatualizadas, builds mais antigas do webpack, Node ficando sem memória, casos extremos de empacotamento do Python e restrições de versão do PHP. Quando um Dockerfile ainda falha, o Railyard tenta de novo com o Railpack usando as versões fixadas no seu código.
• Repositórios com vários serviços. Um arquivo compose ou um repositório com vários Dockerfiles oferece criar todo serviço de uma vez, com os bancos de dados que precisar.

• Alertas de métrica em latência p95, taxa de 5xx, memória ou CPU, checados todo minuto, com um aviso de acompanhamento quando as coisas se recuperam.
• Logs de acesso: toda requisição pelo proxy é registrada com método, caminho, status, duração e cliente, e é buscável junto com os logs do seu app.
• OpenTelemetry: dê a um app um endpoint OTLP e o Railyard define as variáveis padrão OTEL_* e envia suas próprias métricas de CPU, memória e requisição para o mesmo lugar.
• Visão de fila de jobs (beta) para Sidekiq, Solid Queue, GoodJob, Resque e Delayed Job, com retry, discard e um alerta de acúmulo.
• Retenção de logs por equipe, com busca em qualquer intervalo de tempo e download em texto puro.

Veja Logs, metrics and alerts.

• Um deploy termina quando os usuários conseguem acessar, não quando o container inicia. O Railyard verifica o app na sua URL HTTPS real antes de mover o tráfego, e um redirecionamento sozinho não passa mais como um app saudável.
• Crash loops pausam. Um processo que continua travando por dez minutos é parado em vez de reiniciado para sempre, e a página do app mostra por que travou. Restart o inicia de novo.
• Progresso em tempo real para trabalhos longos. Criar um servidor, backups, restaurações, importações e redimensionamentos mostram suas etapas, saída recente e tempo restante, e continuam rodando se você sair da página.

Repositórios sem Dockerfile agora constroem automaticamente com Cloud Native Buildpacks, usando camadas de runtime pré-construídas em vez de compilar uma linguagem a partir do código-fonte. Seu repositório é lido do mesmo jeito que o Heroku lê, então um app migrando geralmente não precisa de mudanças.

Um Procfile declara os tipos de processo e o comando de release. Processos web e worker iniciam a partir dele, e a entrada release: roda antes de a nova versão receber tráfego.

Veja Build methods.

• Conecte o GitHub instalando o Railyard GitHub App uma vez, depois escolha repositórios numa lista. Repositórios privados clonam com tokens de curta duração, pushes fazem deploy, e commits recebem uma verificação de status.
• Conecte o GitLab, no gitlab.com ou self-managed, com um token de acesso em Team → Git providers.
• Ambientes de preview para toda pull request e merge request, removidos quando fecham. Ambientes de staging podem ser promovidos para produção.
• Todo deploy falho se explica: a causa provável, a correção, e a linha de log que mostra isso, na página do deploy, no dashboard e no canvas.

Veja Connect GitHub e Environments and previews.

• Equipes com papéis de owner, admin, developer e viewer, e membros que podem ser limitados a apps específicos.
• Login com dois fatores com qualquer app autenticador, mais códigos de backup.
• Uma API REST com tokens com escopo por equipe, e um cliente de linha de comando construído sobre ela.
• Notificações para deploys, servidores offline e crash loops, enviadas para o Slack, um webhook ou e-mail.
• Aprovações de deploy: deploys de produção podem esperar um admin aprovar.
• Log de atividade de todo deploy, mudança de configuração e ação de servidor.

• Crie um servidor na DigitalOcean, Hetzner, Vultr, AWS ou OVHcloud a partir do painel com seu próprio token de API, ou conecte qualquer servidor Linux via SSH. O Railyard termina a configuração, configura o firewall e mantém atualizado.
• Todo app recebe um hostname e um certificado TLS assim que faz o deploy. Adicione domínios personalizados, servidos diretamente ou redirecionados para o principal, com o status do certificado na aba Domains.
• Jobs agendados com histórico de execução e Run now.
• Métricas do servidor com gráficos de CPU, memória e disco, e alertas quando um disco enche ou o uso fica alto.
• Modo de manutenção por app.

Veja Add a server.

Adicione um banco de dados a um app e o Railyard roda ele no mesmo servidor, cria credenciais só para aquele app e define as variáveis de conexão no próximo deploy.

• Postgres (com pgvector), MySQL, Redis, MongoDB, Elasticsearch, Memcached, RabbitMQ, InfluxDB e object storage compatível com S3.
• Backups numa agenda com a retenção que você escolher, restauração com um clique, e um verificador que restaura cada backup num banco de dados temporário para provar que funciona.
• Volumes persistentes para apps que escrevem em disco, com seus próprios backups.

Veja Databases and backups.

O Railyard faz o deploy de um repositório Git num servidor que é seu: ele clona o código, constrói e transmite o log de build para o seu navegador conforme roda.

• Releases sem downtime. A nova versão inicia ao lado da antiga e só recebe tráfego depois de passar numa verificação de prontidão. Uma verificação que falha deixa a versão antiga servindo.
• Processos web e worker, cada um com seu próprio comando e número de réplicas, mais um comando de release que roda antes do tráfego se mover.
• Variáveis de ambiente, criptografadas em repouso e editáveis uma a uma ou coladas como um bloco .env.
• Rollback para qualquer release anterior com um clique.
• Fontes privadas: clones autenticados por token, submódulos, argumentos de build, segredos de build, e imagens pré-construídas de um registro privado.