PostgreSQL gestionado en Dockup: guía completa
PostgreSQL gestionado en Dockup: crea una base de datos, conecta un servicio de forma segura, consulta el tamaño y los logs, haz copias de seguridad, restaura datos de forma segura y añade usuarios de solo lectura.
PostgreSQL gestionado proporciona a una aplicación una base de datos aprovisionada con operaciones de ciclo de vida independientes del contenedor del servicio. Dockup admite la creación, el inicio y la detención, los logs, la consulta del tamaño, las copias de seguridad, la restauración desde la plataforma, los usuarios de solo lectura, la migración entre nodos y las redes privadas.
El principio operativo clave es la separación: la imagen de la aplicación es desechable, los datos de PostgreSQL son duraderos, las credenciales son secretos y la recuperación de la base de datos debe probarse de forma independiente del rollback de la aplicación.
¿Cómo se crea una base de datos PostgreSQL gestionada?
Selecciona el workspace correspondiente y crea la base de datos:
dockup db create \
--name main-db \
--type postgresql \
--json
Enumera las bases de datos para confirmar el slug y el estado exactos:
dockup db list --json
Las operaciones de base de datos utilizan destinos project/db:
dockup db size production/main-db --json
Espera a que termine el aprovisionamiento antes de asociar una aplicación. No adivines el hostname, el puerto, el nombre de usuario ni la contraseña a partir del nombre de la base de datos.
El plan Free permite tres bases de datos en un workspace e incluye un crédito inicial de 10 $. Los planes de pago —Hobby, por 5 $; Pro, por 20 $ al mes— permiten un número ilimitado de bases de datos, workspaces y deployments. El consumo de CPU, RAM y disco se mide por minuto frente al saldo de uso incluido.
¿Cómo se conecta una aplicación de forma segura?
Obtén los datos de conexión de la base de datos desde la interfaz de bases de datos de Dockup y trata la cadena de conexión como un secreto. No la pegues en el repositorio ni en el transcript del agente.
Configúrala en el servicio:
dockup env set DATABASE_URL="$DATABASE_URL" \
--secret \
-s production/api \
--json
dockup deploy production/api --wait --json
El redeploy es necesario porque el proceso en ejecución recibió su entorno al iniciarse. El valor almacenado aparece enmascarado al leer la configuración del entorno.
Configura el connection pooling de la aplicación de forma deliberada. Demasiados workers de aplicación con pools grandes pueden agotar las conexiones de la base de datos aunque la CPU y la memoria parezcan estar en niveles normales. Define el tamaño del pool según la carga de trabajo y la capacidad de la base de datos, no según el número máximo que acepte un framework.
Prueba una conexión nueva después del deployment. Un endpoint de health puede confirmar que el proceso HTTP está activo sin demostrar que se puede establecer una sesión nueva con la base de datos.
La guía sobre variables de entorno y secretos explica la rotación de credenciales y la salida enmascarada.
¿Cómo protege la red privada el tráfico de PostgreSQL?
Activa una red privada del proyecto:
dockup network enable production --json
Los servicios y las bases de datos gestionadas de ese proyecto reciben hostnames estables con el formato <slug>.internal. Haz redeploy de la aplicación para que reciba las variables de conexión internas inyectadas.
Para eliminar el listener público de la base de datos y hacer que solo sea privada:
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
Hacer que la base de datos sea solo privada recrea su contenedor, pero conserva los datos. Programa y verifica el cambio como una operación de base de datos, no como una modificación de DNS inocua.
La red privada controla la ruta, mientras que las credenciales de PostgreSQL controlan la identidad y la autorización. Conserva ambos controles. Los proyectos separados no pueden comunicarse entre sí porque cada proyecto tiene su propia red.
El artículo sobre redes privadas y dominios internos explica la topología completa.
¿Cómo funcionan las copias de seguridad y la restauración de PostgreSQL?
Enumera las copias de seguridad existentes:
dockup db backups production/main-db --json
Inicia una copia de seguridad en el servidor:
dockup db backup production/main-db --json
El comando de copia de seguridad crea una copia compatible con la base de datos, no una copia en caliente del volumen sin procesar. Registra el ID de la copia, la fecha y hora de creación, la versión de la base de datos y el motivo.
Dockup admite la restauración de copias de seguridad de bases de datos gestionadas desde la plataforma. La referencia actual de la CLI no documenta un comando dockup db restore, por lo que esta guía no inventa ninguno. Realiza la restauración desde la interfaz de Dockup compatible, selecciona la copia exacta, obtén la aprobación para producción y verifica el resultado.
Un plan de restauración debe incluir:
- Punto de recuperación y ventana prevista de pérdida de escrituras.
- Congelación de escrituras de la aplicación o comportamiento durante el mantenimiento.
- Compatibilidad de la base de datos y las extensiones.
- Copia de seguridad reciente del estado actual, cuando sea útil.
- Responsable y aprobación de la restauración.
- Reconexión de la aplicación y smoke test.
- Registro de auditoría e incidente.
Las copias de seguridad no se consideran verificadas hasta que un restore drill se completa correctamente. Utiliza una base de datos que no sea de producción o un entorno de recuperación aprobado para probar el procedimiento.
Conserva las copias de seguridad según una política aprobada. Elimina los puntos de recuperación obsoletos únicamente mediante la interfaz de bases de datos compatible, después de verificar que ningún requisito de recuperación o compliance depende aún de ellos.
¿Cómo funcionan los usuarios de PostgreSQL de solo lectura?
Los usuarios adicionales de solo lectura son útiles para analytics, investigaciones de soporte, deployments de preview y herramientas que deben consultar datos sin escribir.
Enumera los usuarios:
dockup db users production/main-db --json
Crea uno con una etiqueta:
dockup db user-add production/main-db \
--label analytics \
--json
Captura las credenciales generadas de forma segura durante la creación y no las reproduzcas en una respuesta del agente. Revoca el usuario adicional mediante la interfaz compatible de gestión de usuarios de la base de datos cuando termine su propósito.
El acceso de solo lectura en la capa de permisos de la base de datos es más sólido que decirle a una herramienta de consultas «no escribas». Aun así, permite acceder a datos de producción que se pueden leer, por lo que se aplican las reglas de privacidad y least privilege.
Dockup crea automáticamente un usuario de base de datos de solo lectura para un preview de PR o de branch en un proyecto con red privada. El preview puede acceder a la misma base de datos de producción en <slug>.internal y leer datos sin obtener permisos de escritura.
¿Cómo se supervisan el tamaño, los logs y la ubicación?
Consulta el tamaño en disco:
dockup db size production/main-db --json
Revisa los logs de runtime de la aplicación para detectar fallos de conexión sin exponer contraseñas ni cadenas de conexión completas:
dockup logs production/api --json
El mantenimiento de la base de datos puede dejar fuera de servicio a los servicios dependientes. Programa las operaciones que cambien el estado, exige una aprobación operativa explícita y comunica el impacto antes de actuar.
Mueve una base de datos entre nodos indicando el ID del nodo de destino:
dockup db migrate production/main-db \
--node <nodeId> \
--json
La migración es una operación con estado. Confirma el estado de las copias de seguridad, las expectativas de mantenimiento, las conexiones de la red privada y las comprobaciones de la aplicación posteriores al traslado.
Checklist de PostgreSQL gestionado en producción
Un runbook completo registra:
| Área | Evidencia necesaria |
|---|---|
| Identidad | Destino project/db exacto |
| Conectividad | Cadena de conexión secreta y sesión nueva verificada |
| Red | Política pública, privada o solo privada |
| Acceso | Rol de la aplicación y usuarios de solo lectura etiquetados |
| Capacidad | Tamaño actual y revisión del crecimiento |
| Copias de seguridad | IDs de copias recientes y retención |
| Recuperación | Restore drill completado correctamente |
| Operaciones | Aprobación del inicio, detención, reinicio y migración |
| Auditoría | Mutaciones de la base de datos trazables a un actor |
El rollback del deployment de la aplicación no restaura PostgreSQL. La restauración de la base de datos no revierte automáticamente el código de la aplicación. Coordina ambos procesos solo cuando la compatibilidad del schema lo requiera.
Para decisiones de scaling más amplias, consulta estrategias de scaling de bases de datos. Para consultar los comandos exactos, utiliza la referencia de la CLI de Dockup.
Diseña las migraciones de schema para el deployment y el rollback
El deployment de la aplicación y el cambio de schema de la base de datos ocurren en momentos diferentes. Una migración segura suele ser backward compatible durante al menos una ventana de release: añade una columna nullable antes de hacerla obligatoria, despliega código que pueda manejar ambos schemas, ejecuta el backfill mediante un proceso controlado y elimina la estructura antigua más adelante.
No hagas que un health check ejecute una migración larga. Si la aplicación inicia varias réplicas, asegúrate de que solo un migration runner pueda ser responsable del cambio. El comando exec del contenedor PRO puede ejecutar un comando puntual y propagar su exit code real:
dockup exec "npm run migrate" \
-s production/api \
--json
Úsalo únicamente cuando el comando de migración haya sido revisado y el servicio se esté ejecutando en el servidor principal compatible. Captura stdout, stderr y el exit code. Un deployment correcto de la aplicación no implica que se pueda ignorar una migración fallida.
Rota las credenciales de la base de datos sin interrupciones
Crea la nueva credencial o el usuario de solo lectura, actualiza el secreto del servicio consumidor, haz redeploy y verifica una conexión nueva antes de revocar la credencial antigua. Los connection pools existentes pueden ocultar una contraseña nueva incorrecta hasta que vuelvan a conectarse.
Para la credencial principal de la aplicación, utiliza la interfaz compatible de Dockup y la política de la base de datos. Para un usuario analítico adicional, crea una cuenta de solo lectura etiquetada y distribúyela únicamente al consumidor aprobado.
El registro de la rotación debe incluir la etiqueta del usuario, los servicios consumidores, los IDs de deployment, la query de verificación, la hora de revocación y el evento de auditoría; nunca la contraseña.
Observa el crecimiento antes de escalar
El tamaño de la base de datos es una señal:
dockup db size production/main-db --json
Combínala con la latencia de las queries de la aplicación, el número de conexiones, el comportamiento de la caché, la duración de las copias de seguridad y el crecimiento del almacenamiento. Una asignación mayor de CPU o memoria puede no solucionar la falta de índices o las queries sin límites.
Consulta estrategias de scaling de bases de datos antes de mover nodos o aumentar recursos. PostgreSQL gestionado reduce el trabajo de aprovisionamiento, pero el diseño del schema y de las queries sigue siendo responsabilidad de la aplicación.
Separa la disponibilidad de la corrección
Un contenedor de base de datos en ejecución demuestra que PostgreSQL está disponible, no que las queries de la aplicación sean correctas. Incluye una conexión nueva de bajo riesgo y una lectura representativa en la verificación posterior al deployment. Para una prueba de escritura, utiliza una transacción específica o un registro de prueba que se pueda eliminar de forma segura.
El runbook de PostgreSQL gestionado también debe indicar si las réplicas, los usuarios de analytics, los previews o los background workers generan presión adicional sobre las conexiones.
Revisa periódicamente el acceso a PostgreSQL
Enumera los usuarios adicionales, confirma que cada etiqueta tenga un responsable activo y elimina las cuentas obsoletas. Esta revisión sencilla evita que el acceso de lectura de PostgreSQL gestionado se acumule cuando terminan los previews, los proyectos de analytics o las investigaciones de soporte.
Empieza con un deployment verificable
Crea una base de datos PostgreSQL que no sea de producción, conecta un servicio de prueba mediante un secreto enmascarado, realiza una copia de seguridad y completa un restore drill antes del cambio a producción.
Empieza gratis en app.dockup.ai. El plan Free cuesta 0 $ al mes, incluye 10 $ de crédito inicial y admite un workspace, tres bases de datos y tres deployments.
Preguntas frecuentes
¿Qué tipos de bases de datos gestionadas admite Dockup?
Dockup admite bases de datos gestionadas de PostgreSQL, MySQL, MongoDB y Redis.
¿Cómo debe recibir una aplicación su cadena de conexión de PostgreSQL?
Trata la cadena de conexión como una variable de entorno secreta, configúrala en el servicio exacto y haz redeploy para que el nuevo contenedor la reciba.
¿Puede Dockup crear un usuario de PostgreSQL de solo lectura?
Sí. El comando de base de datos user-add crea un usuario adicional de solo lectura y devuelve su contraseña una sola vez durante la creación.
¿Existe un comando documentado dockup db restore de la CLI?
La referencia actual de la CLI no documenta ninguno. Dockup admite la restauración de copias de seguridad mediante la interfaz de la plataforma, así que utiliza esa vía compatible en lugar de inventar un flag o un comando.
¿El rollback de la aplicación restaura la base de datos PostgreSQL?
No. El historial de deployments de la aplicación y el historial de copias de seguridad de la base de datos son sistemas de recuperación independientes y deben coordinarse cuando los cambios de schema requieran ambos.