Ir al contenido

Buscar en la documentación

Busca en la documentación de Skiffly

Redes

Dominios generados y propios con TLS automático, red privada entre servicios por nombre y proxies TCP públicos para bases de datos.

Dominios generados#

Cualquier servicio HTTP puede obtener un dominio bajo skiffly.cloud con un certificado ya emitido:

Servicio → Configuración → Red → Generar dominio. El dominio se ve como api-x1y2.skiffly.cloud y enruta al puerto del servicio.

Los dominios son por entorno: el mismo servicio tiene dominios distintos en production y en staging. Generar dos veces devuelve el dominio existente. Cada dominio apunta al puerto en el que escucha el servicio; el primer dominio se expone al contenedor como SKIFFLY_PUBLIC_DOMAIN.

Dominios propios#

  1. Agrega el dominio: Configuración → Red → Agregar dominio propio, skiffly domain app.example.com o customDomainCreate.

  2. Crea los dos registros DNS que Skiffly imprime:

    app.example.com.            CNAME  edge.skiffly.cloud.
    _skiffly.app.example.com.   TXT    "<token de verificación>"

    Los dominios apex (example.com) necesitan un proveedor que soporte ALIAS/ANAME o CNAME flattening.

  3. Verifica: skiffly domain status app.example.com o customDomainVerify(id). Cuando el registro TXT resuelve, el dominio se enruta y se emite un certificado de Let's Encrypt, normalmente en menos de un minuto. No hace falta volver a desplegar.

skiffly domain app.example.com
skiffly domain status app.example.com     # imprime los registros y el estado de verificación
skiffly domain delete app.example.com

Cada dominio se sirve tanto en http:// como en https://; todavía no hay redirección forzada, así que redirige desde la app si lo necesitas (X-Forwarded-Proto está definido). Los dominios propios con comodín no están soportados.

Red privada#

Los servicios del mismo proyecto y entorno comparten una red privada. Cada servicio es alcanzable en su slug (el nombre del servicio en minúsculas; SKIFFLY_PRIVATE_DOMAIN) en su puerto, sin necesidad de dominio:

http://api:8080
postgres://postgres:…@postgres:5432/app
redis://redis:6379
  • El hostname privado funciona solo dentro del entorno; production no puede alcanzar a staging.
  • El tráfico entre proyectos está bloqueado por política de red; internet es alcanzable en sentido saliente, salvo el puerto 25.
  • Las bases de datos de plantillas escuchan solo en la red privada. ${{Postgres.DATABASE_URL}} ya usa el hostname privado.
  • Los hostnames privados resuelven a las réplicas del servicio; el puerto es el del servicio, no el PORT de quien llama.

Proxies TCP#

Los servicios que no son HTTP (Postgres, MySQL, Redis, Mongo, un servidor de juegos) pueden exponerse en un host:puerto público:

skiffly connect postgres          # crea un proxy tras confirmar y abre psql
skiffly proxy add --port 5432     # edge.skiffly.cloud:2xxxx → puerto 5432 del contenedor
skiffly proxy list
skiffly proxy delete 21543

El proxy es edge.skiffly.cloud:<puerto> con un puerto único en 20000–29999, aplicado de inmediato a un servicio en ejecución (syncStatus: ACTIVE; CREATING hasta el primer despliegue). El tráfico va directo al contenedor sin TLS, así que el servicio debe exigir contraseña. Hasta cinco proxies por servicio y entorno. Un servicio con proxy TCP no puede usar App Sleeping.

Todavía no#

No existen IPs salientes estáticas, una capa CDN/WAF, dominios propios con comodín ni reenvío de correo. El tráfico saliente sale desde la IP del nodo.