Moltaro 0.0.53-beta
Release date: 2026-09-09
Backups created before a Managed App moved to another virtual machine can be deleted successfully again. Administrators can finish previously failed cleanup and free backup slots without changing the application’s data or storage.
Highlights
Section titled “Highlights”- Backup cleanup follows the application’s current virtual machine after a transfer.
- Retrying cleanup respects active restore and deployment operations.
- Portal-only delivery leaves running applications on their existing runtime.
Detailed changes
Section titled “Detailed changes”Backups after a virtual-machine transfer
Section titled “Backups after a virtual-machine transfer”Deleting an older reference-based backup now sends its retention-release request to the application’s current workspace, instead of the virtual machine that originally created the backup. The backup’s recorded creation location remains unchanged for its history.
Administrators can use Backups > Retry cleanup for affected failed deletions. Backup slots are freed only after artifact cleanup succeeds. An active restore or deployment blocks both the initial deletion and its retry. Other retained backups and files still used by the application remain protected.
Database and upgrade impact
Section titled “Database and upgrade impact”No database or upgrade impact: this publication introduces no schema migration or application-runtime upgrade. Portal activation can briefly interrupt portal requests; Managed Apps continue running. Existing backup formats and recovery dependencies are unchanged. Reference-based backups still require their original Object Storage binding for file recovery.
Deployment and operator actions
Section titled “Deployment and operator actions”Deploy using PortalOnly. Portal and documentation become 0.0.53-beta; all
three Managed Apps retain runtime 0.0.52-beta and their current images. No agent
replacement, runtime/update package publication or application restart is needed.
After publication, retry only the previously requested failed cleanup entries from backup administration, then create the required fresh backup through the normal Managed App backup action. Do not edit quota counts or backup catalog states manually. Portal activation uses a PortalDb recovery point and can roll back to the previously active Portal release.
Compatibility and breaking changes
Section titled “Compatibility and breaking changes”No known compatibility or breaking changes. Portal API authorization, backup formats, application placement, account ownership and Object Storage bindings are unchanged. Cleanup requires a valid current application placement.