Moltaro 0.0.15-beta

Release date: 2026-08-10

This release makes production Portal and Managed App hosts self-maintaining: disk-consuming release artifacts and logs are bounded, low-space operations fail before mutating a system, RabbitMQ recovers under a stable identity, and backup snapshot reconciliation is deterministic and observable. It also reorganizes public hierarchy and business-logic documentation around the tasks operators, developers, and AI agents actually perform.

Highlights

Portal retains only its current and immediately previous application release, the two newest local PortalDB recovery dumps, the new runtime package, and runtime packages still referenced by an Available Managed App backup.
Managed runtime VMs retain at most two local release recovery points plus the active runtime ZIP and expanded package. Durable Managed App backups and file bodies remain in object storage and are never removed by this local policy.
Release, database-backup, and package-extraction operations calculate their worst-case working space and a protected host reserve before they start.
Host journals, rsyslog files, and Docker container logs now have explicit source-controlled limits on both existing and newly provisioned hosts.
RabbitMQ uses a stable node identity, authenticated health checks, explicit vhost/user reconciliation, and fail-closed startup when its durable state is inconsistent.
Snapshot-release commands use deterministic identities and stop producing duplicate successful housekeeping entries during the 15-minute Portal reconciliation cycle.

Detailed changes

Portal host retention and release safety

Deployctl measures the runtime archive, expanded package, update staging, database recovery work, and a protected reserve before uploading or replacing a release. Insufficient space aborts before a production mutation.
A successful Portal deployment prunes only direct child release directories that are neither the current nor previous release. Path containment and symlink checks prevent retention from escaping the configured release root.
Runtime package cleanup reads the live PortalDB backup catalog at cleanup time. It keeps the new runtime and every package version referenced by an Available backup, fails closed when a retained backup lacks a package version, and leaves prepared update artifacts untouched.
PortalDB recovery retention keeps the two newest local pre-release dumps. This is independent from Managed App backups in S3 and never deletes a Managed App backup.
PublicSite suppresses routine ASP.NET and EF command noise while preserving application Information events and all warnings and errors.

Managed runtime VM capacity, logs, and cleanup

Runtime agent 0.1.40 installs and validates source-controlled journald, rsyslog, and logrotate policies as a startup prerequisite. New Runtime VMs receive the same files through cloud-init; existing VMs receive them through the agent deployment.
Full runtime replacement keeps at most two local PostgreSQL release recovery directories, the active downloaded ZIP, and the active expanded package. Obsolete local releases and caches are removed only after the replacement and smoke checks succeed.
API, Web, Worker, and RabbitMQ containers use Docker’s bounded json-file logging driver with three 50 MiB files per container.
Managed backup creation budgets the database dump, embedded file payloads, staging/final duplication, and protected reserve. It fails before stopping an application if the host cannot safely complete the backup.

RabbitMQ recovery and application readiness

Every installation uses the stable Compose hostname moltaro-rabbitmq, preventing Docker-generated hostnames from creating a new Erlang node and empty Mnesia directory after container recreation.
API and Worker wait for an authenticated RabbitMQ health check, rather than treating a running process as proof that the application vhost is usable.
moltaroctl validates that .env, API configuration, and Worker configuration agree on the RabbitMQ user, password, and vhost; secret files are written with owner-only permissions.
Startup reconciles the application vhost, user, password, administrator tag, and permissions. One bounded restart is allowed for a recoverable partial metadata state; a second failure blocks readiness with a concrete diagnostic.

Backup snapshot reconciliation

Portal reconciliation remains a 15-minute crash-repair loop for distributed backup/snapshot state. Snapshot records are database pins over immutable S3 generations; they are not local copies of file bodies.
CompleteRelease command IDs are derived from the Runtime VM and typed request, so retrying the same expired snapshot is idempotent across service restarts and reconciliation passes.
Successful internal snapshot-maintenance commands no longer crowd the recent agent-operation list. Queued, running, and failed commands remain visible.

Documentation and reproducible topology

Production, Hetzner, on-premise, backup, and Deployctl runbooks now distinguish durable object storage from disposable local recovery/cache data and document the exact retention, capacity, logging, RabbitMQ, and reconciliation contracts.
The deployment contract separates provider-neutral requirements from the current Hetzner adapter so another domain, region, or provider can reproduce the same topology without copying undocumented host state.
Public hierarchy guidance moved under Configuration and business-logic guidance moved under Developer. Navigation, internal links, public AI-agent entry points, and agent-document contract tests follow the new structure.

Database and upgrade impact

There is no Workspace/PortalDb schema change or bulk data rewrite. Each Managed App is stopped only for full runtime replacement and ordinary startup/schema verification. Portal switches atomically after its recovery point and smoke checks; failed replacement retains the previous release and recovery data.

Deployment and operator actions

Publish 0.0.15-beta as a full Managed App runtime replacement. Do not prepare or apply a Managed App update package.
Deploy Portal, regenerated public documentation, and runtime agent 0.1.40, then replace API, WebApp, Worker, RabbitMQ configuration, and runtime package for east sos 1, OMS, and Questionnaire.
Recreate the application containers so the stable RabbitMQ hostname, authenticated health check, dependency ordering, and Docker log rotation are active. Preserve each workspace database and managed S3 binding.
Preserve all Available Managed App backups. Package artifacts referenced by those backups must remain available even when no running app uses that older runtime.
Verify host free-space reserve, local-retention evidence, journald/logrotate configuration, authenticated RabbitMQ health, all application routes, and a sequential reboot of the Portal VM followed by the shared Runtime VM.
Store provider credentials, DNS authority, signer key material, database secrets, and other external recovery inputs in the encrypted recovery bundle; they are intentionally not committed to the repository.

Compatibility and breaking changes

No supported Runtime API, Portal API, Package SDK type, workspace schema, or persisted business-data contract is removed.
Host provisioning now requires systemd-journald, rsyslog, and logrotate on the supported Linux topology. Deployctl and runtime-agent install and validate the required configuration; an unsupported host fails readiness instead of running with unbounded logs.
RabbitMQ is intentionally recreated with a stable hostname. Existing queues and application credentials are reconciled; operators must not override the Compose hostname or manually edit application RabbitMQ configuration.
Local recovery and cache retention is intentionally stricter. Durable backup retention is unchanged, but operators must not treat the runtime VM’s local release directories as the backup system.
Public documentation URLs for hierarchy and business-logic guides changed to their new Configuration and Developer locations. Repository and agent-facing links are updated in the same release.