Redes privadas y dominios .internal en Dockup

La red privada permite que los servicios y las bases de datos gestionadas de un mismo proyecto de Dockup se comuniquen sin enviar el tráfico entre recursos del proyecto a través de la internet pública. Cada recurso recibe un hostname estable con el formato <slug>.internal, mientras que los proyectos independientes permanecen aislados entre sí.

La red se habilita de forma opcional. Al activarla, se conectan los recursos existentes del proyecto sin exigir que el tráfico de la aplicación cambie de inmediato, y los servicios reciben variables de conexión internas después de volver a desplegarse.

¿Cómo reduce la exposición pública el networking entre servicios?

Un endpoint público de base de datos es accesible desde internet incluso cuando la autenticación bloquea los usos no autorizados. Una ruta privada elimina esa exposición para el tráfico de la aplicación y proporciona a los servicios un nombre interno estable que no depende de una dirección pública.

El mismo principio se aplica a las llamadas entre servicios. Una API puede llamar a un worker, a un servicio de administración interno o a un backend a través de la red del proyecto, en lugar de hacerlo mediante un dominio público personalizado.

Ruta del tráfico	Ruta pública	Ruta privada
API a PostgreSQL	Host y puerto públicos	main-db.internal
Web a API	Dominio público personalizado	api.internal
Worker a Redis	Host y puerto públicos	app-redis.internal
Preview a la base de datos de producción	Credencial pública de la base de datos	Usuario interno de solo lectura
Llamada entre proyectos	Requiere un endpoint público	Bloqueada por el aislamiento de proyectos

Privado no significa sin autenticación. Sigue utilizando usuarios de base de datos, autorización de servicios y secrets. La red determina la accesibilidad; las credenciales determinan los permisos.

¿Cómo se habilita la red privada de un proyecto?

Habilita la red para el slug del proyecto:

dockup network enable production --json

La operación conecta los servicios y las bases de datos gestionadas a la red del proyecto. Los listeners públicos existentes permanecen disponibles de forma predeterminada, por lo que la adopción puede ser gradual.

Vuelve a desplegar cada servicio de aplicación que deba recibir variables de entorno internas:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup inyecta datos de conexión como DATABASE_URL_INTERNAL, la URL interna específica de la base de datos y las variables internas de host, además de los valores de host y puerto de los servicios. Inspecciona las claves del entorno del servicio sin exponer secrets:

dockup env list -s production/api --json

No construyas manualmente una URL a partir de un nombre visible. Los slugs de los recursos determinan el hostname <slug>.internal.

Antes de cambiar la configuración de la aplicación, verifica que todas las dependencias se encuentren en el mismo proyecto. Los proyectos independientes tienen redes separadas y no pueden resolverse ni alcanzarse entre sí mediante la ruta interna.

¿Cómo cambian los dominios .internal la configuración de los servicios?

El DNS interno proporciona un nombre estable aunque los contenedores y los nodos subyacentes cambien. Un servicio de API con el slug api es accesible como api.internal desde los servicios del mismo proyecto; una base de datos con el slug main-db es accesible como main-db.internal.

Da prioridad a las variables de conexión inyectadas cuando estén disponibles. Estas incluyen el protocolo, las credenciales, el nombre de la base de datos y el formato del host correctos. Una cadena creada manualmente puede omitir TLS, la codificación de la contraseña o los parámetros de la base de datos.

Migra una dependencia cada vez:

1. Habilita la red.
2. Vuelve a desplegar el servicio consumidor.
3. Confirma que la variable interna existe.
4. Cambia la aplicación para que la utilice.
5. Despliega con --wait.
6. Verifica las conexiones nuevas.
7. Observa los logs de ejecución y el tiempo de respuesta.
8. Continúa con la siguiente dependencia.

Un servicio puede conservar su dominio público personalizado para el tráfico de los usuarios y utilizar hostnames privados para las llamadas al backend. Las rutas públicas y privadas corresponden a distintos límites de confianza.

La guía sobre variables de entorno y secrets explica por qué los cambios de conexión requieren volver a desplegar.

¿Cómo se configura una base de datos gestionada para que solo sea privada?

Después de que todos los consumidores necesarios utilicen la ruta interna, elimina el listener público:

dockup db private production/main-db --json

Restaura el acceso público y privado cuando sea necesario:

dockup db private production/main-db --off --json

Esta operación de base de datos recrea el contenedor y conserva los datos. Planifica una ventana de mantenimiento adecuada para la carga de trabajo, confirma que exista un backup reciente y prueba la reconexión de la aplicación.

Antes de configurarla como solo privada, comprueba lo siguiente:

• Todos los servicios de producción que utilizan la base de datos están en el mismo proyecto.
• Las herramientas operativas no requieren el endpoint público.
• El acceso de las previews utiliza la ruta privada compatible.
• Existe un backup y se entiende el proceso de recuperación.
• Los connection pools reintentan las conexiones de forma segura.
• El destino exacto project/db está registrado.

No se puede acceder directamente a una base de datos configurada como solo privada desde el portátil de un operador a través de la internet pública. Utiliza el acceso compatible de la plataforma y los diagnósticos a nivel de aplicación, en lugar de reabrir el listener de forma improvisada.

Para las operaciones de base de datos, consulta PostgreSQL gestionado.

¿Cómo acceden las previews de PR a los datos de producción de forma segura?

Cada preview de PR o de una rama de Dockup recibe su propio despliegue y URL aislados. En un proyecto con red privada, la preview se une a la red del proyecto y puede resolver <slug>.internal.

Dockup crea automáticamente un usuario de solo lectura para la base de datos gestionada de producción que utiliza la preview. La preview puede consultar datos con la misma estructura que los de producción, pero no puede escribir con ese usuario.

Este diseño reduce el riesgo de que una feature branch modifique registros de clientes, pero el acceso de lectura también tiene consecuencias:

• En la preview pueden aparecer datos personales o confidenciales.
• El código nuevo de la aplicación podría registrar los datos consultados en los logs.
• Una URL de preview vulnerable podría exponer los resultados de las consultas.
• Las consultas costosas pueden afectar a la carga de producción.
• Las suposiciones sobre el esquema pueden diferir entre la rama y producción.

Habilita el despliegue de previews únicamente conforme a una política revisada:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Utiliza el entorno aislado de la preview para feature flags y secrets que no sean de la base de datos. No sustituyas la credencial automática de solo lectura por la credencial de escritura de producción.

¿Cómo se debe observar y solucionar los problemas de una red privada?

Empieza por la topología y la configuración, en lugar de asumir que existe una incidencia en la plataforma.

Síntoma	Área probable	Comprobación
No se encuentra el nombre	Slug o proyecto incorrecto, o el servicio no se ha vuelto a desplegar	Lista de servicios y claves del entorno
Conexión rechazada	Recurso detenido o puerto incorrecto	Estado y logs de la base de datos o del servicio
Error de autenticación	Credencial incorrecta	Rotación del secret y usuario
Funciona por la ruta pública, pero falla por la privada	Variable interna o adopción de la red	Habilitar la red y volver a desplegar
La preview puede leer, pero no escribir	Política de solo lectura esperada	No sustituyas la credencial
Falla la llamada entre proyectos	Aislamiento esperado	Utiliza una API pública autenticada

Inspecciona los logs de ejecución de la aplicación:

dockup logs production/api --json

Inspecciona el tamaño de la base de datos y los errores de conexión de la aplicación:

dockup db size production/main-db --json
dockup logs production/api --json

No incluyas las URL internas de conexión completas en las notas de una incidencia. Pueden contener credenciales, aunque el hostname en sí no sea secreto.

Plan de migración y rollback

Mantén el listener público durante la primera fase. Si el despliegue interno falla, restaura la configuración anterior de la aplicación y vuelve a desplegarla. Configura la base de datos como solo privada únicamente después de que la ruta interna haya demostrado estabilidad.

Para deshabilitar la red completa del proyecto:

dockup network disable production --json

Debe ser un rollback deliberado, no el primer paso para solucionar problemas. Deshabilitar la red afecta a todos los recursos conectados del proyecto.

Registra las mutaciones de red mediante el audit log:

dockup audit --writes --json

Checklist de producción para redes privadas

Un runbook completo de red privada incluye el slug del proyecto, los slugs de los servicios y las bases de datos, los hostnames internos, los nombres de las variables inyectadas, la política de listeners públicos, la política de acceso de las previews, el estado de los backups, el orden de los redeployments y la ruta de rollback.

La CPU, la RAM y el disco siguen facturándose según el uso y midiéndose por minuto; el routing privado es una decisión de arquitectura, no una clase fija de instancia. Utiliza Precios de PaaS explicados para elaborar el modelo de costes.

La referencia de Dockup CLI contiene los comandos actuales de red y base de datos. Para el aislamiento general de los despliegues, consulta las prácticas recomendadas de seguridad.

Modela la autorización de servicios por separado de la accesibilidad

Un hostname interno solo demuestra que el emisor se encuentra en la red del proyecto. No demuestra qué servicio realizó la solicitud ni si ese servicio puede ejecutar la acción. Mantén la autenticación de la aplicación para las API internas sensibles y las credenciales de base de datos para el acceso a los datos.

Utiliza secrets específicos por servicio en lugar de un único token interno compartido. Si una preview recibe acceso de solo lectura a la base de datos, no le proporciones también un token de servicio de producción que pueda activar escrituras a través de una API.

Mide el efecto del cambio

Compara la latencia de conexión, la tasa de errores y el tiempo de respuesta p95 antes y después de cambiar a endpoints internos. El objetivo principal es el aislamiento y una ruta privada estable; cualquier mejora de latencia debe medirse, no darse por garantizada.

dockup uptime production/api --hours 24 --json

Conserva la ventana de observación y el ID del despliegue. Esto proporciona a la modificación de la red privada un criterio de finalización medible, en lugar de terminar con un simple «el DNS resolvió correctamente».

Documenta la excepción de la ruta pública

Es posible que alguna integración externa, herramienta de operador o servicio entre proyectos todavía necesite un endpoint público. Enumera cada excepción, su autenticación, responsable y condición de eliminación. Esto evita que el listener público permanezca indefinidamente porque nadie recuerda por qué existe.

Un despliegue completo de red privada puede ser parcial, pero todas las rutas públicas deben ser intencionadas.

Revisa las dependencias internas después de cambiar nombres

Cambiar el nombre o sustituir un recurso puede modificar el slug utilizado para el direccionamiento .internal. Haz inventario de los consumidores antes de cambiar nombres, vuelve a desplegarlos con las variables inyectadas actualizadas y verifica cada conexión privada.

Así mantendrás estable la red privada a medida que evolucione el proyecto.

Empieza con un despliegue verificable

Habilita la red en un proyecto que no sea de producción, migra una dependencia a su endpoint .internal y demuestra la ruta de rollback antes de eliminar cualquier listener público.

Empieza gratis en app.dockup.ai. El plan Free cuesta 0 $ al mes, incluye un crédito inicial de 10 $ y admite un workspace, tres bases de datos y tres despliegues.

Preguntas frecuentes

¿Qué hostname utilizan los recursos de Dockup en la red privada?

Cada servicio y base de datos gestionada del mismo proyecto es accesible mediante un hostname estable con el formato <slug>.internal.

¿Habilitar la red privada elimina el acceso público a la base de datos?

No. De forma predeterminada, la red se añade al acceso existente. Utiliza el comando independiente de base de datos private para eliminar el listener público después de que los consumidores utilicen la ruta interna.

¿Pueden comunicarse entre sí de forma privada distintos proyectos de Dockup?

No. Cada proyecto tiene una red aislada, por lo que la comunicación entre proyectos debe utilizar una interfaz pública y autenticada adecuada.

¿Puede una preview de PR escribir en la base de datos de producción?

En un proyecto con red privada, Dockup aprovisiona automáticamente un usuario de base de datos de solo lectura para la preview, lo que permite leer, pero impide escribir con esa credencial.

¿Por qué deben volver a desplegarse los servicios después de habilitar la red?

El redeployment proporciona al nuevo contenedor las variables de conexión internas y permite que la aplicación se inicie con la configuración del endpoint privado.