Secure software deployment starts with separating code, configuration and persistent data
A reliable Linux deployment should not treat an application folder as a single object that contains source code, installed dependencies, live data, secrets and rollback history. Those materials have different lifecycles. Application code should be replaceable, configuration should be permission controlled, and user data should survive a release change without being copied into every rollback. This maintenance release verified those boundaries before any cleanup. The running application continued to use its dedicated service account, private configuration remained in the protected system configuration area, and journal data remained in persistent application storage.
The permission audit found inactive deployment workspaces and packaged configuration copies that were more permissive than the live service files. The live canonical files were already restricted, but duplicate copies still increase exposure. The repair removed two verified-unused staging workspaces and changed every retained environment-like file to owner-only access. A second full-filesystem audit then confirmed that no real environment file had public read permission or group/world write permission. The Paystub, rules, complaints and Journal services remained active throughout the verification.
Delivered in this update
- Service accounts stay isolated by application
- Persistent data is not stored inside replaceable release folders
- Canonical configuration remains outside public source and web roots
- Duplicate deployment credentials are removed after safe verification
Slim versioned releases provide rollback without duplicating a gigabyte of build dependencies
The largest storage problem came from several Journal rollback directories that were full copies of the application. Each copy included a build dependency tree larger than one gigabyte, even though the production server used a much smaller standalone application bundle. Five historical rollbacks plus the former active directory consumed several gigabytes and did not provide useful version metadata. Keeping more copies would have delayed the problem rather than creating a dependable release process.
The replacement uses named immutable runtime releases with a current pointer and explicit metadata for application version, revision and deployment time. The production bundle keeps the Next.js standalone server and only the three launcher dependency families needed for the embedded database and migration connection. The active beta release is about 123 MB and the retained previous release is about 164 MB. A health-checked switch moved the service to the compact current release, then six inactive full-directory trees were deleted. The persistent journal data and existing database backups were not part of that deletion.
Delivered in this update
- Current and previous Journal releases are individually identified
- Standalone runtime replaces duplicated build-time dependencies
- Release switching uses a stable current pointer
- Daily retention keeps two completed Journal releases only
Disk monitoring now warns while there is still time to act
Monitoring is most useful before a capacity problem becomes an outage. The Command Center previously displayed current disk use but classified storage as an issue only at 90 percent. That threshold leaves little room for package installation, database growth, temporary builds or backup creation. The new policy introduces a warning at 75 percent and keeps 90 percent as the critical threshold. At the end of the cleanup, the root filesystem reported 48 percent used and roughly 26 GB available.
A separate system service now checks disk capacity every 15 minutes, writes a small non-sensitive health record and logs the result through the operating system journal. The Command Center reads that record alongside its direct capacity measurement, shows the background guard status and continues to refresh the dashboard every 60 seconds. If the critical threshold is reached, the guard fails visibly so it appears in normal failed-service reporting. This lightweight approach provides persistent capacity supervision without adding a large monitoring stack to a small server.
Delivered in this update
- 75 percent disk warning and 90 percent critical threshold
- Background capacity check every 15 minutes
- Protected Command Center refresh every 60 seconds
- System journal record and visible critical service failure
Retention runs after health validation, not before it
Automatic cleanup is safe only when it understands which release is active and when the new release has proved that it can run. The Journal retention tool considers only completed release directories that contain a release manifest. It preserves the active target and one previous completed version, validates that every deletion candidate is a direct child of the controlled release directory and refuses unexpected paths. A daily timer enforces the same policy even when no deployment occurs.
The protected Command Center follows a similar pattern. Its deployment now finishes application health, reverse-proxy syntax, multi-factor access policy and authenticated-route checks before it prunes old dashboard releases. It keeps three completed dashboard versions because those releases are small. This is the operating model Auto Secure Login will use across suitable projects: compact build artifacts, stable configuration and data paths, bounded rollback, clear health checks and private backups for recovery. The change improves reliability for current services and gives future custom software deployments a more predictable maintenance foundation.
Delivered in this update
- Cleanup begins only after the new service passes health checks
- Unexpected or active paths are never deletion candidates
- Command Center retains three small releases after protected-route validation
- Source history and private backups complement local rollback retention