Redes

Más allá de los dominios públicos y las reglas por solicitud de Edge rules, las apps también necesitan hablar entre sí de forma privada, y a veces estar detrás de un CDN de terceros u obtener un solo certificado para todo un dominio wildcard. Esta página cubre esos tres casos.

Red privada entre apps

Cada app recibe un nombre privado, <name>.railyard.internal, en lugar de que las apps tengan que encontrarse por IP pública:

• Mismo servidor: el nombre es un alias de red de Docker, así que se resuelve directo al contenedor en el propio puerto de la app (container_port). Esto no necesita configuración.
• Servidor distinto, red privada desactivada: una referencia a la otra app sigue funcionando, solo que no es privada — se resuelve a la dirección pública normal https:// de esa app en lugar de fallar.
• Servidor distinto, red privada activada: actívala desde Servers → Private network → Turn on (admins). Cada servidor del equipo se une a una red WireGuard cifrada (10.210.0.0/16), y <name>.railyard.internal entonces se resuelve, desde cualquier servidor del equipo, hacia donde la app realmente corre — a través de la malla, hacia su puerto publicado. El canvas dibuja ese enlace como privado. Los contenedores que ya están corriendo adoptan el nuevo resolver en su siguiente despliegue o reinicio.

Referencia otro servicio con ${{api.RAILYARD_PRIVATE_URL}} (para una app llamada api) en lugar de fijar un host a mano — consulta Variables y secretos. Se expande al caso que corresponda de los anteriores, así la misma referencia sigue funcionando si las dos apps terminan después en servidores distintos.

Más puertos públicos

Settings → General → More public ports acepta un name:port por línea (por ejemplo, metrics:9100) para un segundo protocolo o interfaz de administración en la misma app. Cada uno obtiene su propia dirección HTTPS — <name>-<app-hostname> — enrutada y certificada de la misma forma que la dirección principal de la app.

Cloudflare al frente de una app

Settings → Networking → Cloudflare pone el CDN, la protección DDoS y el WAF de Cloudflare al frente de la dirección propia de la plataforma de una app, cuando el DNS de esa dirección ya está en el DNS administrado de Railyard y ese DNS corre en Cloudflare (no Route 53, y no un dominio personalizado cuya zona Railyard no gestiona — la tarjeta explica qué caso aplica).

• Activarlo pone en modo proxy el registro DNS la próxima vez que Railyard lo escribe — el siguiente despliegue o un failover, no de forma instantánea.
• El edge proxy confía en los rangos de IP publicados por Cloudflare y lee la IP real del visitante desde CF-Connecting-IP, así que el rate limiting, el bloqueo por país, el WAF y los access logs siguen viendo al visitante real en lugar del edge de Cloudflare una vez que una app activa esto — consulta Edge rules.
• HTTPS sigue funcionando: el certificado propio de Let’s Encrypt de Railyard se sigue emitiendo y sirviendo en el origen. Define el modo SSL de Cloudflare como Full (strict), que verifica ese certificado en lugar de confiar en lo que presente el origen.
• Tú igual tienes que apuntar los nameservers de este dominio hacia Cloudflare — Railyard solo escribe el registro DNS que ya administra, nunca los nameservers de una zona.

Certificados wildcard mediante DNS-01

Un dominio wildcard (*.example.com, consulta Domains) usa por defecto TLS on-demand: cada subdominio obtiene su propio certificado de Let’s Encrypt la primera vez que alguien lo visita, así que 20 subdominios significan 20 certificados. Para tener en cambio un solo certificado que cubra todo el wildcard:

1. Team settings → DNS credentials → agrega un token de API de Cloudflare (acotado a Zone:DNS:Edit para la zona, no la API key global) o una clave de acceso de Route 53 (route53:ChangeResourceRecordSets y route53:ListResourceRecordSets sobre la hosted zone). Se guarda cifrada, y se usa solo para el challenge DNS-01.
2. En la pestaña Domains de la app, agregar o editar una dirección wildcard muestra un dropdown de DNS credential. Elige una para solicitar un único certificado wildcard; déjalo vacío para mantener el comportamiento on-demand.

Eliminar una credencial hace que sus dominios wildcard vuelvan a los certificados on-demand en lugar de romperse.

Tráfico saliente

Las conexiones salientes de una app salen desde la IP pública de su propio servidor — no hay un pool de NAT compartido, ni un cargo extra por una dirección estable para darle a la allowlist de IP de una API de terceros, como sí necesita una plataforma multi-tenant. La IP solo cambia si la app misma se muda a otro servidor.

Ver también

• Domains — la dirección por defecto, dominios personalizados y la verificación de propiedad.
• Edge rules — reglas por solicitud: redirecciones, encabezados, CORS, rate limiting, bloqueo por país, el WAF.
• Variables and secrets — referenciar la URL privada de otro servicio.
• Add a server — activar la red privada.