Cómo actualizar de forma segura las aplicaciones Docker basadas en PHP en tu servidor doméstico

Un parche de seguridad de PHP dentro de un contenedor normalmente llega mediante una imagen reconstruida. Descargar esa imagen y ponerla en servicio son pasos distintos. El plan de actualización también debe proteger la base de datos y los archivos persistentes que sobreviven al contenedor.

Haz una copia de seguridad de los datos de la aplicación, de su base de datos cuando corresponda y de la configuración antes de cambiar la imagen. Descarga una versión compatible con el parche, recrea el servicio, verifica el contenedor de reemplazo y comprueba la acción crítica del usuario antes de registrar la actualización como completa.

1. Registra el despliegue actual

Confirma el directorio del proyecto y los nombres de los servicios con docker compose ps. Registra las etiquetas y los identificadores de las imágenes actuales con docker compose images, además de dónde se encuentran los volúmenes persistentes y los datos de la base de datos. Guarda una copia protegida de la configuración de Compose sin exponer secretos en registros compartidos.

Consulta las notas de la versión de la imagen de destino para comprobar la corrección de PHP. Una etiqueta llamada latest no demuestra que incluya un parche concreto. Si usas una referencia fija por digest, debe cambiarse por la referencia verificada de la imagen de reemplazo.

2. Haz una copia de seguridad coherente

Usa el método de copia de seguridad documentado por la aplicación. Conserva la configuración, los archivos y una copia de seguridad de la base de datos correspondientes a un punto de recuperación coherente. Coordina la suspensión de escrituras o el modo de mantenimiento cuando la aplicación lo requiera. Una copia del sistema de archivos del directorio de una base de datos activa no sustituye en todos los casos a una copia de seguridad válida de la base de datos.

Mantén la copia de recuperación fuera del alcance de escritura de la aplicación y asegúrate de saber cómo restaurarla. Conserva la configuración anterior y la referencia de la imagen, pero recuerda que restaurar una imagen antigua vulnerable no debería volver a ponerla directamente en internet público.

¿Por qué puede que revertir una imagen no restaure la aplicación?

Una imagen de contenedor normalmente contiene código ejecutable, mientras que la base de datos y los archivos cargados se guardan en almacenamiento persistente. Una actualización puede cambiar el esquema de la base de datos o reescribir el estado de la aplicación. Si vuelves a la imagen anterior, el código antiguo se encontrará con datos nuevos; el resultado puede ser incompatible aunque la imagen se inicie.

Para una aplicación con estado, conserva un conjunto de recuperación coherente: la exportación compatible de la base de datos, la configuración, los archivos pertinentes de la aplicación y la referencia al artefacto anterior. Las instrucciones de copia de seguridad de Nextcloud identifican los datos necesarios para esa aplicación; otras aplicaciones tienen sus propias reglas. Una caché de imágenes por sí sola no puede reconstruir datos que falten o se hayan migrado.

3. Descarga la imagen y recrea el servicio previsto

Para una imagen publicada por el mantenedor, actualiza la referencia de imagen del servicio a una versión fija compatible y luego sigue este ejemplo desde el directorio correcto del proyecto. Sustituye app por el servicio de tu aplicación PHP:

docker compose pull app
docker compose up -d --no-deps app
docker compose ps
docker compose exec -T app php -v

Docker indica que pull descarga imágenes sin iniciar contenedores; up aplica cambios en la imagen o la configuración recreando los contenedores. En este caso, --no-deps limita el cambio al servicio seleccionado. Úsalo solo cuando los servicios dependientes ya estén en buen estado y sean compatibles.

Para las compilaciones personalizadas, actualiza la imagen base de PHP o los paquetes pertinentes, vuelve a compilar mediante tu proceso habitual y despliega la imagen resultante. Repite el proceso para los trabajadores que utilicen ese entorno de ejecución. No apliques parches desde un shell de contenedor efímero y des por hecho que la solución persistirá al recrearlo.

4. Valida la aplicación antes de restablecer el acceso

Comprueba localmente los registros en busca de errores de inicio, sin compartir tokens ni rutas privadas. Confirma el entorno de ejecución web y, después, prueba el inicio de sesión, la exploración de archivos, una carga pequeña y una tarea en segundo plano. Verifica que las rutas de los volúmenes y los permisos de propiedad sigan coincidiendo con la disposición prevista.

Si restringiste el acceso público, restablécelo solo después de que se superen las comprobaciones de versión y funcionalidad. El estado correcto del contenedor por sí solo no demuestra que las cargas ni las tareas en segundo plano funcionen.

¿Cómo verificas el contenedor nuevo sin probar todo el servidor?

Comprueba por separado tres capas: sustitución, tiempo de ejecución y comportamiento del usuario. Registra el identificador de la imagen del contenedor después de recrearlo, inspecciona el tiempo de ejecución en el servicio correcto y, después, realiza una acción crítica representativa. En una aplicación de archivos, lee un archivo de prueba conocido y, si las cargas son esenciales, sube un archivo pequeño y prescindible. Es posible que un error relacionado con la base de datos no aparezca en una página de inicio sencilla.

Docker documenta la diferencia entre descargar imágenes y crear o sustituir contenedores. Vincula el resultado con la identificación del entorno de ejecución y la planificación de copias recuperables para que el registro de la actualización demuestre algo más que la ejecución correcta de un comando de shell.

5. Recupera el sistema con cuidado si falla la validación

Mantén el servicio aislado mientras investigas. Restaura juntos los archivos de la aplicación y el estado de la base de datos cuando las reglas de migración de la aplicación lo requieran; cambiar solo la imagen puede ser arriesgado después de una actualización del esquema. No uses docker compose down -v como atajo para solucionar problemas, ya que puede eliminar volúmenes con nombre.

Si usas ZimaCube 2, separa el registro de actualizaciones de tus archivos generales y conserva copias de seguridad independientes. Una actualización correcta termina con un entorno de ejecución conocido, funciones de la aplicación operativas y un procedimiento de recuperación que puedas explicar.

Explora ZimaCube 2 NAS doméstico de nube personal para tu almacenamiento privado y la configuración de aplicaciones autohospedadas. La seguridad del software depende de los servicios instalados, su configuración y las actualizaciones verificadas.

Fuentes y alcance

Verificado el 22 de octubre de 2026. Las recomendaciones de implementación deben ajustarse a la documentación de la aplicación y del proveedor; estos artículos no determinan la exposición de productos específicos.

• Descargar imágenes con Docker Compose
• Iniciar con Docker Compose
• Ejemplo de copia de seguridad de Nextcloud