Moltaro 0.0.11-beta

Release date: 2026-08-06

Moltaro 0.0.11-beta makes managed S3 file-body storage the complete default for Portal-created Managed Apps, adds a resumable database-to-S3 migration workflow, and hardens Portal storage-signer recovery after a host restart.

Highlights

Managed Apps use S3 from their first upload

• Portal-created and Portal-restored Managed Apps now bootstrap the workspace file-body setting as AmazonS3; ordinary standalone/on-prem installations continue to use PostgreSQL by default.
• A new storage binding is created with uploads enabled. Runtime-agent refuses to declare an installation ready unless the binding, API and Worker signer configuration, capability files, compose wiring, and workspace database all agree on the same ready S3 contract.
• Restore preserves reads of legacy database-backed bodies and reconciles new writes to the restored app’s managed S3 binding before startup.

Safe migration of legacy database file bodies

• moltaroctl file-storage legacy-to-s3 adds plan, run, verify, rollback, finalize, and compact operations for an installed workspace.
• Migration streams bounded multipart uploads, verifies size and SHA-256 from both S3 and PostgreSQL, records durable generations, and resumes after an interruption without exposing signer or Object Storage credentials.
• Migration generations obey the canonical objects/<generation-guid> storage contract and carry a dedicated verification-policy marker, keeping rollback and finalization isolated from normal S3 uploads. An interrupted pre-release noncanonical generation is repaired only under strict unreferenced-state gates.
• Migration operations use the installed API and Worker signer capabilities according to their existing scopes; exact-object metadata reconciliation is available to both app-scoped capabilities without granting bucket-wide access.
• Signer throttling now returns and honors a bounded Retry-After interval, while five consecutive descriptor failures stop the resumable run instead of flooding its report with the same infrastructure failure.
• PostgreSQL bodies remain available until an exact zero-error verification is complete. Finalization then removes only unreferenced legacy bodies, and the explicit compaction step returns table space to the operating system.

Production recovery hardening

• Portal deployment now enables and explicitly restarts both storage-signer systemd instances after switching the release symlink, then verifies both enabled and active state before signer readiness probes. An already-running signer can no longer retain the prior release’s binary in memory.
• The enabled-service contract is explicit and applies only to declared services; unrelated companion services retain their existing restart semantics.
• Deployctl now cross-checks every PortalDb Running Managed App against its live API, Web, Worker, and RabbitMQ containers. It repeats that check after the build and immediately before the first production mutation, so a stopped or drifted application cannot produce a partial fleet replacement.
• Source-controlled unit files, Caddy configuration, deployment contracts, and recovery documentation now describe the full Portal and shared-runtime rebuild path.

Database and upgrade impact

The Workspace schema does not change for the legacy-body move. Existing descriptors and generation records are updated only by the explicit offline moltaroctl workflow. PortalDb changes the default only for newly inserted managed file-body bindings; bindings that were explicitly disabled remain disabled.

Runtime and deployment

• WebApp, API, Worker, workspace migrations, moltaroctl, Portal, public documentation, storage signer, and runtime-agent form one 0.0.11-beta release boundary.
• Runtime-agent 0.1.37 installs an idempotent, source-controlled private-host mapping for the signer on the runtime VM as well as in API/Worker containers, then performs a live, secret-safe capability probe against the exact binding ID and version before a Managed App can start. Host-side operations such as moltaroctl file-storage legacy-to-s3 therefore use the same private TLS route.
• Runtime-agent 0.1.38 orders runtime PostgreSQL after Docker and verifies the Docker-bridge listener before applications start, preventing post-reboot API and Worker restart loops. Runtime-agent 0.1.39 bounds event replay by count and serialized bytes; Portal gives authenticated agent ingress a separate 512 KiB limit while the private storage signer remains at 128 KiB.
• Folder purge now evaluates managed-upload rows through the current S3 body contract, so an uploaded file and then its emptied folder can be purged without a stale database-body invariant failure.
• Existing Managed Apps are advanced through full runtime replacement, not a published delta update. New Managed Apps select the same published base runtime.
• Managed App backups are never deleted automatically. A runtime artifact may be retired only after every retained backup that references it has been removed or its restore guarantee has been explicitly abandoned.