¿Subdominio, subdirectorio o dominio independiente? Cómo elegir una estructura de URL para una aplicación autohospedada
Elegir dónde reside una aplicación autohospedada afecta a la configuración del proxy inverso, las cookies, las devoluciones de llamada de autenticación, los webhooks, TLS, el trabajo de migración y los límites administrativos. Utiliza esta guía para seleccionar una estructura de URL y validarla antes del lanzamiento.
Por qué la estructura de URL es una decisión operativa, no solo una decisión de marca
Una URL forma parte del contrato público de una aplicación. Los usuarios la guardan, los navegadores le aplican reglas de origen y cookies, los proveedores de identidad pueden registrarla, los emisores de webhooks entregan solicitudes en ella, y los clientes de API o el contenido embebido pueden almacenarla. Por tanto, cambiar la URL más adelante puede afectar a algo más que los marcadores y los enlaces de búsqueda.
Los tres patrones más habituales son un subdominio dedicado como https://app.example.com, un subdirectorio detrás de un sitio existente como https://example.com/app y un dominio independiente como https://exampleapp.com. La mejor opción depende del modelo de despliegue documentado de la aplicación y de tus requisitos operativos, no simplemente de qué dirección parece más corta.
Una distinción técnica fundamental es el origen. Un origen web se basa en el esquema, el host y el puerto; la ruta no forma parte del origen. Como resultado, https://example.com/app comparte un origen con otro contenido en https://example.com, mientras que https://app.example.com utiliza un host distinto y, por tanto, un origen diferente. Esta diferencia puede ser importante para el comportamiento del navegador, el diseño de integraciones y las expectativas de aislamiento.
- Elige la URL pública antes de invitar a usuarios, conectar un proveedor de identidad o publicar endpoints de webhooks.
- Trata la URL canónica de la aplicación como una configuración que debe documentarse y mantenerse.
- No des por hecho que un proxy inverso puede hacer que cualquier aplicación funcione correctamente bajo un prefijo de ruta.
Los tres patrones de un vistazo
Un subdominio dedicado sitúa la aplicación en una dirección como https://crm.example.com. Para muchas aplicaciones autohospedadas, esta es la disposición pública más directa porque normalmente la aplicación puede tratar / como su ruta base. El proxy inverso enruta por nombre de host, y los enlaces generados, los recursos estáticos y las redirecciones no necesitan incluir un prefijo de ruta pública adicional.
Un subdirectorio sitúa la aplicación bajo un nombre de host existente, por ejemplo https://example.com/analytics. Esto puede crear un sitio público unificado y ser útil cuando una empresa debe presentar un único nombre de host. Sin embargo, introduce el requisito de que tanto el proxy inverso como la aplicación entiendan correctamente la ruta base /analytics.
Un dominio independiente sitúa la aplicación en un nombre distinto, como https://example-portal.com. Esto puede hacer más claros los límites de producto, cliente, unidad de negocio o gobernanza. También crea una superficie separada de DNS, TLS, propiedad del dominio y ciclo de vida que gestionar.
- Subdominio dedicado: normalmente es la opción predeterminada de menor complejidad para una aplicación con su propio inicio de sesión e integraciones.
- Subdirectorio: apropiado solo después de que la documentación oficial de la aplicación y un despliegue de preproducción confirmen la compatibilidad con URL relativas.
- Dominio independiente: útil cuando un límite público, administrativo u organizativo claro es más importante que mantener la aplicación bajo el dominio principal de la marca.
Empieza por la aplicación: verifica la compatibilidad documentada con URL base y proxy inverso
Empieza por la documentación de instalación y proxy inverso de la propia aplicación. Busca específicamente configuraciones compatibles denominadas URL base, URL externa, URL del sitio, URL raíz, URL relativa, raíz web, URL pública, proxy de confianza, cabeceras reenviadas o un término similar. La terminología varía según el producto y la compatibilidad es específica de cada producto.
Un proxy puede eliminar un prefijo público antes de reenviar una solicitud. Por ejemplo, un proxy puede aceptar /app y reenviar la solicitud a un backend que escucha en /. El middleware StripPrefix de Traefik realiza este tipo de eliminación de prefijo y proporciona el prefijo eliminado en X-Forwarded-Prefix. Pero eliminar una ruta en el proxy no hace automáticamente que la aplicación sepa que su dirección pública incluye esa ruta.
La aplicación debe seguir generando enlaces públicos, URL de recursos, redirecciones, destinos de formularios y URL de devolución de llamada con el prefijo correcto. La documentación oficial también puede revelar limitaciones. GitLab, por ejemplo, documenta la instalación con URL relativa como una alternativa, pero recomienda su propio dominio o subdominio en circunstancias normales y describe limitaciones. Es un recordatorio útil de que no se debe generalizar el comportamiento de un producto a otro.
- Lee la documentación de despliegue del proveedor antes de seleccionar un subdirectorio.
- Confirma si la aplicación admite una URL relativa o una raíz web, no solo un proxy inverso genérico.
- Identifica las cabeceras de proxy necesarias y las configuraciones de proxy de confianza.
- Registra la URL externa canónica exacta en la documentación de despliegue.
- Realiza una prueba de preproducción con la URL pública prevista, no solo con una dirección interna o directa del contenedor.
Autenticación e integraciones: URL de devolución de llamada, enlaces de correo, contenido embebido y webhooks
La autenticación suele hacer visible una migración de URL. Las integraciones OAuth pueden requerir que los endpoints de redirección se registren en el servidor de autorización. Cuando se registra una URI de redirección completa, OAuth 2.0 exige una comparación simple de cadenas con la URI solicitada. Por tanto, un cambio de https://example.com/app/callback a https://app.example.com/callback puede requerir una modificación de configuración en el proveedor de identidad, incluso si la propia aplicación funciona.
Haz inventario de todos los servicios externos que almacenan o muestran la URL pública. Habitualmente incluyen configuraciones de inicio de sesión único, correos de restablecimiento de contraseña e invitación, páginas embebidas externamente, configuración de clientes de API, clientes móviles o de escritorio y emisores de webhooks. Un valor antiguo puede pasar desapercibido hasta que un usuario sigue un flujo de correo poco frecuente o una integración en segundo plano intenta realizar una entrega.
Los webhooks merecen un paso de validación separado porque su emisor es un cliente HTTP externo. La URL de payload configurada debe actualizarse cuando sea necesario, y la entrega debe probarse después de que la nueva dirección esté activa. Para servicios que validan certificados TLS, confirma que el endpoint sirve el certificado válido esperado y que es accesible públicamente en la ruta requerida.
- Enumera cada URI de redirección OAuth o SSO antes del lanzamiento o la migración.
- Envía invitaciones de prueba reales, restablecimientos de contraseña y correos de notificación a un buzón controlado.
- Prueba el contenido embebido desde el sitio o producto que realmente lo alojará.
- Haz inventario de los emisores de webhooks entrantes, actualiza la configuración de sus endpoints y desencadena una entrega de prueba.
- Comprueba si los clientes de API y las herramientas de automatización tienen URL base codificadas de forma fija.
DNS, certificados TLS y enrutamiento para cada patrón
La elección de un nombre de host crea trabajo de DNS y certificados. Las autoridades de certificación validan el control de los nombres de dominio incluidos en un certificado, por lo que el nombre de host seleccionado debe resolverse y enrutarse de una manera compatible con el método de validación elegido. La validación HTTP-01 de Let's Encrypt recupera un desafío en /.well-known/acme-challenge/ por el puerto 80. Por tanto, el DNS y el enrutamiento público forman parte de la preparación para el lanzamiento de la aplicación, no una tarea que deba dejarse para después de configurar la aplicación.
Un subdominio normalmente necesita un registro DNS para ese nombre de host y un certificado que lo cubra. Un dominio independiente requiere el mismo trabajo para un nombre de dominio diferente. Un subdirectorio no añade un nombre de host, pero sí requiere reglas de enrutamiento por ruta precisas y coexistencia con las rutas, redirecciones y gestión de desafíos del sitio principal.
Los certificados comodín son una decisión de diseño independiente. Let's Encrypt documenta que HTTP-01 no puede emitir certificados comodín; su emisión requiere validación DNS-01. No elijas un enfoque con comodines únicamente para evitar planificar nombres de host individuales, salvo que puedas operar de forma segura el proceso de validación DNS requerido.
- Confirma la propiedad del DNS y quién puede modificar los registros relevantes.
- Verifica que el nombre de host previsto se resuelva antes de emitir el certificado y del lanzamiento público.
- Comprueba que se pueda acceder al puerto 80 y a la ruta del desafío ACME al utilizar validación HTTP-01.
- Define la precedencia de enrutamiento para que el sitio principal, las rutas de la aplicación y las rutas de desafío no entren en conflicto.
- Cuando se use Docker, expón solo los puertos que necesiten acceso externo; un proxy inverso puede alcanzar los servicios mediante la red del host o de Docker sin publicar públicamente todos los puertos de los contenedores.
Datos y gobernanza: decide quién es responsable del límite
La estructura de dominio debe reflejar la titularidad operativa además de la experiencia de usuario. Considera quién controla el registro del dominio, los registros DNS, los cambios relacionados con certificados, la administración de la aplicación, los contactos de facturación y el acceso de emergencia. Una URL técnicamente conveniente puede convertirse en un riesgo operativo si depende de una cuenta personal o del acceso DNS de un equipo no relacionado.
Un dominio independiente puede ser útil cuando un cliente, una empresa adquirida, una unidad regulada o un producto autónomo necesita un límite público y administrativo más claro. Un subdominio dedicado puede proporcionar un límite práctico dentro de un dominio principal gestionado de forma centralizada. Un subdirectorio suele reservarse mejor para los casos en que compartir un nombre de host es realmente necesario y se ha verificado la compatibilidad de la aplicación.
Ninguna de estas opciones resuelve automáticamente la gobernanza de acceso. Define quién administra la aplicación, quién dispone de acceso DNS, quién aprueba los cambios de integración, dónde se gobiernan las copias de seguridad y cómo se transfiere el acceso si cambia el personal o los proveedores.
- Documenta el propietario legal y operativo de cada dominio y zona DNS.
- Evita que una sola persona controle el registrador, el DNS y el acceso de administrador de la aplicación.
- Asigna responsables para la configuración del proveedor de identidad, las configuraciones de webhooks y los procedimientos de recuperación.
- Utiliza un dominio independiente cuando un ciclo de vida o límite de propiedad independiente sea un requisito principal.
Planifica la migración: las redirecciones ayudan, pero no actualizan todas las dependencias
Un subdominio suele ser más fácil de cambiar que un despliegue en subdirectorio porque normalmente la aplicación puede permanecer en /. Eso no significa que los cambios de nombre de host no tengan consecuencias. El nuevo nombre de host cambia el origen del navegador, puede necesitar un nuevo certificado y registro DNS, y puede requerir actualizaciones de devoluciones de llamada registradas, destinos de webhooks, clientes de API, plantillas de correo y listas de permitidos.
Un traslado de subdirectorio a subdominio puede simplificar la futura configuración del proxy, pero sigue cambiando la URL canónica. La guía de migración documentada de GitLab ofrece un ejemplo concreto útil: cambiar la URL modifica las URL de los repositorios remotos, que los usuarios pueden tener que actualizar manualmente. Las redirecciones pueden conservar los enlaces heredados accesibles desde el navegador, pero no reescriben la configuración remota almacenada por cada usuario o sistema de terceros.
Prueba las redirecciones según los tipos de solicitud reales que recibe tu aplicación. Las redirecciones HTTP son comportamiento del cliente, no una garantía de que todos los clientes respondan de la misma forma. La semántica HTTP también distingue el comportamiento de los métodos: 301 y 302 pueden hacer que un POST se convierta en GET, mientras que 307 y 308 conservan el método. No supongas que una redirección probada en un navegador demuestra que un cliente de API o emisor de webhook se comportará correctamente.
- Crea un inventario de las URL antiguas antes de cambiar la dirección canónica.
- Actualiza la configuración de la aplicación, los proveedores de identidad, los emisores de webhooks, los clientes de API, la documentación y las comunicaciones dirigidas a usuarios.
- Mantén un plan deliberado de redirecciones para el tráfico del navegador, incluida una fecha de retirada y un enfoque de monitorización.
- Prueba por separado los flujos de trabajo basados en POST y los clientes externos de la navegación GET ordinaria.
- Indica a los usuarios cuándo deben actualizar manualmente repositorios remotos guardados, marcadores, configuraciones de clientes o listas de permitidos.
Preguntas frecuentes
¿Es mejor un subdominio o un subdirectorio para una aplicación autohospedada?
Un subdominio dedicado suele ser la opción predeterminada más sencilla porque la aplicación puede funcionar desde /. Elige un subdirectorio solo cuando necesites compartir un nombre de host y la documentación oficial de la aplicación, junto con una prueba de preproducción, confirmen una compatibilidad fiable con URL relativas o raíz web.
¿Puede un proxy inverso hacer que cualquier aplicación funcione en un subdirectorio?
No. Un proxy inverso puede eliminar un prefijo de ruta pública antes de reenviar solicitudes, pero la aplicación debe seguir generando recursos, redirecciones, enlaces e integraciones usando el prefijo público. El enrutamiento del proxy por sí solo no proporciona compatibilidad de URL base a nivel de aplicación.
¿Las cookies hacen que los subdirectorios sean inseguros?
Path de una cookie limita cuándo un navegador envía una cookie, pero no es un límite de seguridad. Las aplicaciones bajo un mismo nombre de host necesitan una configuración de cookies deliberada y no deben depender de la separación por rutas como protección entre servicios administrados de forma independiente.
¿Qué debe cambiar al mover una aplicación a un nuevo nombre de host?
Revisa la URL canónica de la aplicación, DNS, el certificado TLS, las URI de redirección OAuth o SSO, los enlaces de restablecimiento de contraseña e invitación, las URL de payload de webhooks, los clientes de API, el contenido embebido, la documentación, las listas de permitidos y los clientes configurados por los usuarios. Las redirecciones pueden ayudar con los enlaces del navegador, pero no actualizan automáticamente las configuraciones externas.
¿Cómo puede ayudar Airbip con el enrutamiento de URL para un despliegue de aplicación gestionado?
Airbip despliega aplicaciones de catálogo como cargas de trabajo Docker en servidores en la nube de Airbip y automatiza el enrutamiento y los certificados TLS mediante Traefik y Let's Encrypt. También incluye comprobaciones DNS, gestión del ciclo de vida de servicios y copias de seguridad diarias, semanales y mensuales configurables. Los clientes pueden utilizar un subdominio de Airbip o un dominio personalizado compatible. El cliente sigue necesitando elegir la URL de aplicación adecuada, verificar la compatibilidad de URL base a nivel de aplicación, configurar identidad e integraciones, y tomar las decisiones pertinentes sobre datos, acceso y gobernanza.
Fuentes y lecturas adicionales
- Traefik StripPrefix middleware documentation — Traefik Labs
- GitLab: Install under a relative URL — GitLab
- GitLab: Migrate from a relative URL to a subdomain — GitLab
- Nextcloud Server Administration Manual — Nextcloud GmbH
- RFC 6265: HTTP State Management Mechanism — IETF
- RFC 6749: The OAuth 2.0 Authorization Framework — IETF
- RFC 6454: The Web Origin Concept — IETF
- RFC 9110: HTTP Semantics — IETF
- Challenge Types — Let’s Encrypt / Internet Security Research Group
- Docker networking overview — Docker