Rede

Além dos domínios públicos e das regras por requisição em Edge rules, os apps também precisam se comunicar de forma privada entre si e, às vezes, ficar atrás de um CDN de terceiros ou ter um único certificado para um domínio wildcard inteiro. Esta página cobre esses três casos.

Rede privada entre apps

Todo app recebe um nome privado, <name>.railyard.internal, em vez de os apps precisarem se encontrar pelo IP público:

• Mesmo servidor: o nome é um alias da rede Docker, então resolve direto para o container na porta do próprio app (container_port). Isso não precisa de nenhuma configuração.
• Servidor diferente, rede privada desligada: uma referência ao outro app ainda funciona, só que não é privada — ela resolve para o endereço público https:// normal daquele app em vez de falhar.
• Servidor diferente, rede privada ligada: ative em Servers → Private network → Turn on (admins). Todos os servidores da equipe entram em uma rede WireGuard criptografada (10.210.0.0/16), e o <name>.railyard.internal passa a resolver, a partir de qualquer servidor da equipe, para onde o app está realmente rodando — pela malha, até sua porta publicada. O canvas desenha esse link como privado. Containers já em execução recebem o novo resolvedor no próximo deploy ou reinício.

Referencie outro serviço com ${{api.RAILYARD_PRIVATE_URL}} (para um app chamado api) em vez de fixar um host direto no código — veja Variáveis e secrets. Isso se expande para qual dos casos acima se aplica, então a mesma referência continua funcionando se os dois apps mais tarde acabarem em servidores diferentes.

Mais portas públicas

Settings → General → More public ports aceita um name:port por linha (por exemplo, metrics:9100) para um segundo protocolo ou interface administrativa no mesmo app. Cada um ganha seu próprio endereço HTTPS — <name>-<app-hostname> — roteado e certificado da mesma forma que o endereço principal do app.

Cloudflare na frente de um app

Settings → Networking → Cloudflare coloca o CDN, a proteção contra DDoS e o WAF do Cloudflare na frente do endereço próprio da plataforma de um app, quando o DNS desse endereço já está no DNS gerenciado do Railyard e esse DNS roda no Cloudflare (não na Route 53, e não em um domínio personalizado cuja zona o Railyard não administra — o card explica qual caso se aplica).

• Ativar isso faz o proxy do registro DNS na próxima vez que o Railyard escrevê-lo — no próximo deploy ou em um failover, não instantaneamente.
• O proxy de borda confia nos intervalos de IP publicados pelo Cloudflare e lê o IP real do visitante a partir do CF-Connecting-IP, então o rate limiting, o bloqueio por país, o WAF e os logs de acesso continuam vendo o visitante real em vez do edge do Cloudflare quando um app ativa isso — veja Edge rules.
• O HTTPS continua funcionando: o certificado Let’s Encrypt do próprio Railyard ainda é emitido e servido na origem. Defina o modo SSL do Cloudflare como Full (strict), que verifica esse certificado em vez de confiar em qualquer coisa que a origem apresente.
• Você ainda precisa apontar os nameservers desse domínio para o Cloudflare você mesmo — o Railyard só escreve o registro DNS que já gerencia, nunca os nameservers de uma zona.

Certificados wildcard via DNS-01

Um domínio wildcard (*.example.com, veja Domains) usa TLS on-demand por padrão: cada subdomínio recebe seu próprio certificado Let’s Encrypt na primeira visita, então 20 subdomínios significam 20 certificados. Para ter um único certificado cobrindo o wildcard inteiro:

1. Em Team settings → DNS credentials → adicione um Cloudflare API token (com escopo Zone:DNS:Edit para a zona, não a chave global da API) ou uma chave de acesso da Route 53 (route53:ChangeResourceRecordSets e route53:ListResourceRecordSets na hosted zone). Armazenado criptografado, usado só para o desafio DNS-01.
2. Na aba Domains do app, adicionar ou editar um endereço wildcard mostra um dropdown de DNS credential. Escolha uma para pedir um único certificado wildcard; deixe em branco para manter o comportamento on-demand.

Remover uma credencial faz os domínios wildcard dela voltarem para certificados on-demand em vez de quebrar.

Tráfego de saída

As conexões de saída de um app saem pelo IP público do próprio servidor — não existe um pool de NAT compartilhado, nem cobrança extra por um endereço estável para colocar na allowlist de uma API de terceiros, como uma plataforma multi-tenant precisa ter. O IP só muda se o app em si se mudar para outro servidor.

Veja também

• Domains — o endereço padrão, domínios personalizados e a verificação de propriedade.
• Edge rules — regras por requisição: redirecionamentos, headers, CORS, rate limiting, bloqueio por país, o WAF.
• Variáveis e secrets — como referenciar a URL privada de outro serviço.
• Add a server — como ativar a rede privada.