Un despliegue seguro separa código, configuración y datos persistentes
Un despliegue confiable en Linux no debe tratar la carpeta de una aplicación como un solo objeto que mezcla código fuente, dependencias instaladas, datos vivos, secretos e historial de retorno. Esos materiales tienen ciclos de vida distintos. El código debe poder reemplazarse, la configuración necesita permisos controlados y los datos del usuario deben sobrevivir a un cambio de versión sin copiarse en cada retorno. Esta actualización verificó esas fronteras antes de limpiar. La aplicación continuó usando su cuenta de servicio dedicada, la configuración privada quedó en el área protegida del sistema y los datos del diario permanecieron en almacenamiento persistente.
La auditoría encontró espacios inactivos de despliegue y copias empaquetadas con permisos más amplios que los archivos usados por los servicios. Los archivos canónicos ya estaban restringidos, pero una copia duplicada todavía aumenta la exposición. La reparación eliminó dos espacios temporales verificados como inactivos y cambió cada archivo de entorno conservado a acceso exclusivo de su propietario. Una segunda auditoría de todo el sistema confirmó que ningún archivo real de entorno tenía lectura pública ni escritura para grupo u otros usuarios. Los servicios de Paystub, reglas, quejas y Journal siguieron activos durante la verificación.
Entregado en esta actualización
- Cuentas de servicio aisladas por aplicación
- Datos persistentes fuera de carpetas reemplazables
- Configuración canónica fuera del código público y de la web
- Credenciales duplicadas eliminadas después de una revisión segura
Las versiones compactas permiten regresar sin duplicar dependencias de compilación
El mayor problema de almacenamiento provenía de varios directorios de retorno del Journal que copiaban toda la aplicación. Cada copia incluía más de un gigabyte de dependencias de compilación, aunque el servidor de producción usaba un paquete autónomo mucho menor. Cinco retornos históricos y el antiguo directorio activo consumían varios gigabytes y no ofrecían metadatos útiles de versión. Conservar más copias solamente habría aplazado el problema en vez de crear un proceso de publicación confiable.
El reemplazo usa versiones de ejecución inmutables con nombre, un puntero actual y metadatos explícitos de versión, revisión y fecha. El paquete conserva el servidor autónomo de Next.js y solo las tres familias de dependencias que necesita el iniciador para la base integrada y la conexión de migraciones. La versión beta activa ocupa cerca de 123 MB y la anterior conservada cerca de 164 MB. Un cambio con prueba de salud movió el servicio a la versión compacta; después se eliminaron seis árboles completos inactivos. Los datos persistentes y las copias existentes de la base no formaron parte de esa eliminación.
Entregado en esta actualización
- Versiones actual y anterior del Journal identificadas por separado
- Ejecución autónoma en lugar de dependencias repetidas de compilación
- Cambio de versión mediante un puntero estable
- Retención diaria limitada a dos versiones completas y válidas
El monitoreo de disco ahora avisa cuando todavía hay tiempo para actuar
El monitoreo resulta más útil antes de que una falta de capacidad se convierta en una interrupción. El Centro de Mando mostraba el uso actual, pero solo clasificaba el almacenamiento como problema al llegar a 90 por ciento. Ese nivel deja poco espacio para instalar paquetes, permitir crecimiento de bases, crear compilaciones temporales o generar respaldos. La nueva política introduce una advertencia a 75 por ciento y conserva 90 por ciento como nivel crítico. Al terminar la limpieza, el sistema raíz mostró 48 por ciento usado y aproximadamente 26 GB disponibles.
Un servicio independiente comprueba la capacidad cada 15 minutos, escribe un registro pequeño sin información sensible y publica el resultado en el diario del sistema operativo. El Centro de Mando lee ese registro junto con su medición directa, muestra el estado del guardián y continúa actualizando el panel cada 60 segundos. Si se alcanza el nivel crítico, el guardián falla de forma visible para aparecer en el informe normal de servicios con errores. Este enfoque ligero ofrece supervisión persistente sin instalar una plataforma de monitoreo grande en un servidor pequeño.
Entregado en esta actualización
- Advertencia a 75 por ciento y nivel crítico a 90 por ciento
- Comprobación de capacidad cada 15 minutos
- Actualización del Centro de Mando cada 60 segundos
- Registro del sistema y fallo visible al llegar al nivel crítico
La retención se ejecuta después de validar la salud
La limpieza automática solo es segura cuando entiende qué versión está activa y cuándo la nueva versión demostró que puede funcionar. La herramienta del Journal considera únicamente directorios completos que contienen un manifiesto de versión. Conserva el objetivo activo y una versión anterior, verifica que cada candidato sea hijo directo del directorio controlado y rechaza rutas inesperadas. Un temporizador diario aplica la misma política aunque no ocurra un despliegue.
El Centro de Mando protegido sigue un patrón parecido. Su despliegue termina primero las pruebas de salud de la aplicación, sintaxis del proxy, política de acceso multifactor y ruta autenticada; solo entonces elimina versiones antiguas del panel. Conserva tres versiones porque esos paquetes son pequeños. Este es el modelo operativo que Auto Secure Login aplicará a los proyectos adecuados: artefactos compactos, rutas estables para configuración y datos, retorno limitado, verificaciones claras y respaldos privados para recuperación. El cambio mejora la confiabilidad actual y crea una base de mantenimiento más predecible para futuros proyectos de software personalizado.
Entregado en esta actualización
- La limpieza comienza después de aprobar las pruebas de salud
- Las rutas activas o inesperadas nunca son candidatas
- El Centro de Mando conserva tres versiones pequeñas verificadas
- El historial de código y los respaldos privados complementan el retorno local