serve.zone/onebox
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 51 Wiki Activity

51 Releases 272 Tags

RSS Feed
  • v32.6.0 c6f3bfd02f
    Compare

    Onebox v32.6.0
    Release / build-and-release (push) Successful in 25m58s
    Details
    Stable

    jkunz released this 2026-09-24 16:17:16 +00:00 | 26 commits to main since this release

    2026-09-24 - 32.6.0

    Features

    • Import a backup download on another host. onebox backup import <service-name> --file <absolute path> --password-stdin makes a download a backup of a service installed on this host, and onebox backup restore <backup-id> restores a backup in place from the CLI, which had no restore. The daemon opens the file itself and refuses a relative path, a symbolic link or a directory. It decrypts the file into a private directory, keeps nothing of it before the AES-256-GCM tag verified, and refuses a wrong password or an altered file as backup-download-unauthenticated. It requires exactly the logical items the file's metadata names, requires the secret bundle to decrypt under this host's ONEBOX_ENCRYPTION_KEY without re-encrypting it, ingests the items through the same ingest-and-record path as backup creation, on the same per-service queue, and is idempotent by the file's SHA-256, recorded on the snapshot and its row as importSha256. Downloads now carry an authenticated backup-manifest entry naming the snapshot format, when the backup was taken, the Onebox release that took it and the service it belonged to; a 32.x download without one is accepted and its metadata derived from its items. Until now the readme told operators to recover Cloudly on another host by restoring in place, but a restore took only a backup id from the local database and a download could not be read back, so no such path existed.

    Fixes

    • Keep the platform-owned environment of the service a restore writes. A restore wrote the backup's hosted-app runtime identity (SERVEZONE_APP_INSTANCE_ID, SERVEZONE_APP_HOST_TYPE, SERVEZONE_RUNTIME_URL, SERVEZONE_APP_CONTROL_TOKEN) and its platform resource credentials over the service's own, so a backup from another host or from before a credential rotation left the service with an identity its host never issued and database credentials that no longer open its database. An in-place restore now keeps the values the service holds, taken from PlatformServicesManager for platform credentials, and an import or clone drops the backup's copies, which also ends the deployment's refusal of a clone whose backup carried the platform-owned identity keys.
    • Restore a Corestore database backup into the service that receives it, whichever service wrote the closure. CorestoreProvider.restoreDatabaseBackup required the receipt's source to be the target service, and its cross-service variant required a database allocation, which ordinary service databases do not carry and Corestore refuses for them, so a backup could not be restored into a service with another id, such as the one Cloudly receives when it is installed again on another host. The options now name the receiving service and no longer take an allocation reference, which no hosted service's database carries.
    Downloads