Moltaro 0.0.34-beta

Release date: 2026-09-03

This release makes File Protection operational for governed manual backups and single-file recovery, with universal Windows and Linux tools, source-scoped access control, immutable recovery evidence, and a secure direct object-storage data path. It also improves cross-platform runtime delivery and introduces a prepared two-phase deployment path that shortens the active production change.

Highlights

• File Protection administrators can enroll backup Agents, define file, directory, or glob Sources, run Protect now, inspect logical Recovery Points, and create revocable restore sessions.
• Universal self-contained Agent and portable Restore packages are available for Windows x64 and Linux x64. The Agent is backup-only; restore remains a separate user-invoked utility.
• Every exact protected file has an isolated, version-pinned Kopia repository. File data travels directly between the client and private object storage and is not proxied through the Moltaro API or Restore Gateway.
• Source-scoped roles and permissions govern administration, backup, history, restore, export, and Agent assignment without exposing physical paths, credentials, object keys, or protected content through the public APIs.
• Production delivery now prepares immutable artifacts and compatibility evidence before promotion, reducing active replacement work to verified activation, recovery points, migrations, sequential runtime replacement, acceptance, and retention.

Detailed changes

File Protection operations and recovery

• Administrators can connect a computer with a short-lived enrollment flow, assign an enrolled Agent to a Source, and manage file, directory, and glob mappings. Physical paths remain local to the Agent and are not returned to other users through the control plane.
• Protect now creates a leased, idempotent manual run. The Agent waits for a stability window, rejects live database files, uploads through a loopback S3 bridge using short-lived grants, and reports bounded recovery metadata.
• Recovery history is paginated and identifies the protected logical paths in each Recovery Point. Restore sessions are explicitly authorized, time-bound, revocable, and pinned to the selected file, snapshot, object versions, and immutable storage view.
• The portable Restore utility reconstructs one authorized file, verifies its size and SHA-256, and publishes it atomically without overwriting an unrelated destination. Restores of directory or glob Sources still select one exact file at a time.
• Each logical path uses an independent repository identity and derived key. A descriptor for one file cannot enumerate or restore another file, while deduplication is retained across versions of the same logical path.
• Finalization is durable and resumable. Recovery Points become visible only after retained object versions and all item metadata are verified and published; interrupted finalization can resume without publishing partial history.
• Operational readiness now covers the storage signer and Restore Gateway. Safe status and diagnostics omit secrets and protected data.

File Protection distribution and extension contracts

• The Windows Agent installs as a hardened LocalSystem service from a fixed machine-controlled location. The Linux package installs a root-owned systemd service under a dedicated account. Neither installer grants source access or bypasses operating-system elevation.
• Agent and Restore packages include their .NET runtime, the pinned Kopia binary, verified upstream provenance, and a payload SHA-256 manifest. Keep an extracted distribution intact; the tools do not self-update.
• The File Protection .NET package contract is version 1.2. It adds safe Source and Recovery Point queries plus idempotent manual-protection operations while continuing to exclude local paths, credentials, repository locators, object keys, exports, and protected content.
• Administrators can assign Source-scoped security associations. The runtime revalidates current permissions for restore grants and completion, so revoked access cannot continue through an earlier UI session.

Runtime and delivery reliability

• Verified download spools now use explicit cross-process coordination and stable platform paths, and packaged Workspace UI assets support the intended Windows and Linux runtime identifiers.
• The release process stages content-addressed Portal, documentation, Agent, runtime, and image artifacts without changing live services. Promotion uses only the frozen prepared runner and verified staged bytes; it does not compile, package, or perform a large artifact upload after the mutation checkpoint.
• Interrupted promotion retains atomic step evidence and can resume from the same preparation, skipping Portal, Agent, and Managed Apps already proven at the exact target version.

Database and upgrade impact

Workspace databases gain File Protection state for Agents, credentials, enrollment, Sources, runs, Recovery Points, recovery items, restore sessions, per-file repository checkpoints, retained object versions, and durable run finalization. PortalDb separates provisioning and runtime data-plane storage capabilities. Existing business entities, files, security assignments, normal Managed App backups, and previously configured protection repositories are not deleted or rewritten.

Each Managed App has ordinary full-runtime replacement downtime while its recovery point is captured, Workspace migrations are applied, and API, WebApp, Worker, PostgreSQL, RabbitMQ, and Restore Gateway readiness are verified. Rollback requires the verified pre-release Workspace recovery point and the previous runtime; Portal rollback additionally requires the pre-release PortalDb recovery point. Operators must not edit migration history or remove new schema objects manually.

Deployment and operator actions

• Publish this version with full ReplaceRuntime for all production Managed Apps. Do not prepare or apply a delta update.
• Keep File Protection disabled unless an administrator intentionally enables and configures it. The release does not create a Source, enroll an Agent, start protection, or issue a restore session by itself.
• When enabling File Protection, configure the protection repository first, assign Source-scoped permissions, download the package for the Agent’s actual operating system, and follow its delivered installation guide. Give the dedicated service identity read/traverse access only to intended source data.
• Preserve the complete Agent/Restore distribution, enrollment state, and recovery descriptor securely. A restore descriptor is a temporary bearer credential even though it contains no storage key or Source master key.
• Require an Available recent automatic backup for every Managed App before promotion and retain the normal pre-release recovery points. After promotion, verify exact target images, all component readiness, empty deployment queues, and current/previous Docker-image retention.

Compatibility and breaking changes

File Protection 1.2 is a coordinated prerelease format break. API, Agent, Restore, and Restore Gateway must be delivered together; earlier development archives and Source-wide checkpoint/password formats are not supported or migrated. Production 0.0.33-beta did not create File Protection Sources, protection runs, or Recovery Points, so no released production backup data requires conversion.

The new File Protection APIs and .NET members are additive to the production surface. Existing File Protection 1.1 status consumers remain valid. The release adds no intentional breaking change to existing Entity, Board, Tasks, backup, or authentication payloads.