Skip to Content
TestingDominios personalizados de app

Dominios personalizados de app

Disponibilidad

La verificación de propiedad de dominio personalizado está implementada, pero el tráfico y la entrega de certificados para dominios personalizados no lo están. El servicio actual puede almacenar una solicitud de dominio, devolver instrucciones DNS, consultar DNS público y permitir solo nombres verificados mediante la puerta Caddy tls-ask prevista.

Aún no añade un hostname verificado al gateway, obtiene un certificado ni enruta solicitudes para ese hostname. No muevas tráfico de producción a esta feature aún. Un estado verified prueba solo la comprobación de propiedad DNS configurada.

Flujo de verificación

  1. Adjunta un hostname a un slug de app.
  2. Publica los registros DNS devueltos.
  3. Pide al servicio que verifique contra resolvers públicos.
  4. Inspecciona el estado devuelto y cualquier error de comprobación.
  5. Sigue usando la URL preview de la plataforma; la verificación no activa el hostname personalizado.

Los subdominios usan una comprobación CNAME contra <slug>.apps.openfactory.tech. Los nombres apex usan un desafío TXT generado más la presencia de un registro A. Un registro A apex no se comprueba contra una dirección de ingress concreta, así que no es validación de ruta.

Superficie REST

MethodPathCurrent result
POST/api/app-gateway/domainsStores a pending domain and returns DNS instructions.
GET/api/app-gateway/domains?app_slug={slug}Lists domain records.
GET/api/app-gateway/domains/{domain}Gets one record.
POST/api/app-gateway/domains/{domain}/verifyPerforms an immediate public-DNS check.
DELETE/api/app-gateway/domains/{domain}Removes the stored record.
GET/api/app-gateway/tls-ask?domain={domain}Returns allow or deny for a verified record; intended for the future Caddy integration.

Ejemplo de solicitud attach:

POST /api/app-gateway/domains Content-Type: application/json { "app_slug": "my-app", "domain": "app.example.com" }

El servicio rechaza zonas de propiedad de la plataforma, propiedad duplicada, hostnames inválidos y más de cinco dominios por app.

Qué falta antes de activación

El uso en producción requiere que todo esto esté completado y probado:

  • configuración del gateway para cada hostname verificado;
  • una ruta de ingress pública decidida que pueda terminar el certificado del cliente;
  • emisión, renovación, inventario de caducidad y alertas de certificados;
  • reconciliación inmediata y periódica tras cambios DNS;
  • autorización del propietario en toda ruta list, read, verify y delete; y
  • una prueba con dominio real que cubra DNS, TLS, routing, renovación, eliminación y rollback.

Hasta que exista esa evidencia, trata la API de dominio solo como vista previa de verificación DNS.