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

59 Releases 280 Tags

RSS Feed
  • v32.20.0 947f8236e7
    Compare

    v32.20.0
    Release / build-and-release (push) Failing after 12m42s
    Details
    Stable

    philkunz released this 2026-09-29 00:14:57 +00:00 | 0 commits to main since this release

    2026-09-28 - 32.20.0

    Features

    • Bundle the Cloudly App Store template 1.9.0 for Cloudly 33.6.0 through @serve.zone/appstore 32.9.0, moved from 32.8.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.9.0 on a host running template 1.2.1, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0 or 1.8.0 needs this release. The template pins the Cloudly 33.6.0 image index code.foss.global/serve.zone/cloudly@sha256:efcb200497b45ea14ef87155ac67a13a9be8eebd67801680122e84b9f3670c26, keeps the 1.8.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0; against 1.8.0 only its image and changelog differ. It marks the upgrade migration-required and backup-before-upgrade because from 1.8.0 and every earlier template Cloudly 33.6.0 runs the forward-only data step deployment-machine-user-grants from 0.22.0 to 0.23.0 at its first start, which keeps on every deployment machine user only the grants a capability check reads and permanently removes the rest, such as the { serviceId, capabilities } grants stored by Cloudly 11; from 1.6.0 and earlier the step runtime-session-protocol-offer from 0.21.0 to 0.22.0 runs before it, and from 1.2.1 the 0.20.0 to 0.21.0 migration of Cloudly 33.0.0 first. No step has an inverse, so stop Cloudly and take a verified backup before upgrading; only that backup goes back. It stays breaking and manual-review because the step removes stored grants and, from 1.7.0 and earlier, the deployment machine users of Cloudly 33.5.0 apply: a username and password deployer, an administrator's deployment reservation and a machine identity or registry bearer issued earlier are refused, so switch every such deployer to a machine-user token before upgrading. Let no deployment run while Cloudly upgrades. Cloudly 33.6.0 stops gracefully on SIGTERM and SIGINT within 8 seconds, below the 10-second stop grace of Docker, so stopping or restarting it no longer leaves a database transaction held and the next start no longer crash-loops on EFENCE_BUSY; the Cloudly 33.5.0 or earlier container that this upgrade stops still lacks that handler, so this one upgrade can still meet the EFENCE_BUSY crash loop until the database server's 30-minute session timeout. The template changelog also names the per-service deployment namespace of new services and the repaired getDeploymentMachineUsers listing, and carries forward the notes of the earlier templates, with the rollout order Cloudly 33.6.0 before Coreflow 33.2.0 from 1.4.0 and earlier. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.9.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 (Cloudly 32.9.1 image, as central runs), 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0 and 1.8.0 (Cloudly 33.0.0, 33.1.0, 33.2.0, 33.3.0, 33.4.0 and 33.5.0 images). App Store 32.9.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.
    Downloads
  • v32.19.0 c7af7566b5
    Compare

    v32.19.0
    Release / build-and-release (push) Failing after 11m16s
    Details
    Stable

    philkunz released this 2026-09-28 13:24:56 +00:00 | 2 commits to main since this release

    2026-09-28 - 32.19.0

    Features

    • Bundle the Cloudly App Store template 1.8.0 for Cloudly 33.5.0 through @serve.zone/appstore 32.8.0, moved from 32.7.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.8.0 on a host running template 1.2.1, 1.3.0, 1.4.0, 1.5.0, 1.6.0 or 1.7.0 needs this release. The template pins the Cloudly 33.5.0 image index code.foss.global/serve.zone/cloudly@sha256:9a803fbc9db00ffcf6ce4bd584c0c8b5a3016f3a94ce75629ddee2f52d2bf72c, keeps the 1.7.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0; against 1.7.0 only its image and changelog differ. It marks the upgrade breaking and manual-review because Cloudly 33.5.0 reserves a deployment only for a deployment machine user: reserveServiceDeployment refuses an administrator, and so a username and password deployer such as tsdeploy with TSDEPLOY_CLOUDLY_USERNAME/TSDEPLOY_CLOUDLY_PASSWORD, with DEPLOYMENT_MACHINE_IDENTITY_REQUIRED, so operators switch every such deployer to a machine-user token (mutateDeploymentMachineUser or Access → Deployment machine users, grants through configureServiceDeploymentMachineUser) before upgrading; a machine identity or registry bearer issued by an earlier release is refused until its holder exchanges its token again, and a deployment in progress during the upgrade is refused for the rest of its run, so no deployment runs while Cloudly upgrades. It stays migration-required and backup-before-upgrade, because Onebox reads these flags from the target version alone: Cloudly 33.5.0 keeps data version 0.22.0 and only adds the collection cloudly_deployment_machine_user_mutations, so from 1.7.0 there is no data step, while from 1.6.0 and earlier the forward-only step runtime-session-protocol-offer from 0.21.0 to 0.22.0 still runs at the first start, and from 1.2.1 the 0.20.0 to 0.21.0 migration of Cloudly 33.0.0 before it; neither step has an inverse, so only the pre-upgrade backup goes back. The template changelog also names the relay config push to the elected relay of every cluster and the invalid refusal of setServiceRuntimeSpec, and carries forward the notes of the earlier templates, with the rollout order Cloudly 33.5.0 before Coreflow 33.2.0 from 1.4.0 and earlier. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.8.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 (Cloudly 32.9.1 image, as central runs), 1.3.0, 1.4.0, 1.5.0, 1.6.0 and 1.7.0 (Cloudly 33.0.0, 33.1.0, 33.2.0, 33.3.0 and 33.4.0 images). App Store 32.8.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • Release tooling: @git.zone/tsdeno 1.12.0, moved from 1.11.0 in package.json and pnpm-lock.yaml. Before every compile and after every tsdeno install --entrypoint it reads the binary's module graph with deno info under the run's resolution flags, including the minimumDependencyAge committed in deno.json, and fails with UNRESOLVED_DEPENDENCY when an npm import does not resolve, because Deno 2.9 exits 0 and leaves such a package out of a binary it reaches only through a dynamic import. Onebox's graph resolves completely, so build:binary passes the new guard unchanged. pnpm 12.6.0 and @types/node 26.6.3 still wait for the seven-day rule.
    Downloads
  • v32.18.0 2691cc1d2c
    Compare

    v32.18.0
    Release / build-and-release (push) Failing after 11m38s
    Details
    Stable

    philkunz released this 2026-09-28 04:42:49 +00:00 | 5 commits to main since this release

    2026-09-28 - 32.18.0

    Features

    • Bundle the Cloudly App Store template 1.7.0 for Cloudly 33.4.0 through @serve.zone/appstore 32.7.0, moved from 32.6.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.7.0 on a host running template 1.2.1, 1.3.0, 1.4.0, 1.5.0 or 1.6.0 needs this release. The template pins the Cloudly 33.4.0 image index code.foss.global/serve.zone/cloudly@sha256:f4f88f0c3765d1b129fa4f3ff68438958e55d4fad598393fb0c686261e46c7ed, keeps the 1.6.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0; against 1.6.0 only its image and changelog differ. It marks the upgrade breaking, migration-required, backup-before-upgrade and manual-review, because Onebox reads these flags from the target version alone: from every earlier template Cloudly 33.4.0 runs the forward-only data step runtime-session-protocol-offer from 0.21.0 to 0.22.0 at its first start, which states protocol: null on Pallet session rows recorded before Cloudly stored a node's protocol offer, and from 1.2.1 the 0.20.0 to 0.21.0 migration of Cloudly 33.0.0 runs before it; neither step has an inverse, so only the pre-upgrade backup goes back. The template changelog names the published-port ranges and symmetric same-port outbound of Cloudly 33.4.0, the SNAT band of new handoff leases, the refusals published-port-reserved, published-port-symmetric-without-egress, published-port-symmetric-inside-overlap and service-deleting, and the node-contract-behind withholding from Pallet nodes below interfaces 32.31.0; from 1.4.0 and earlier the rollout order Cloudly 33.4.0 before Coreflow 33.2.0. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.7.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 (Cloudly 32.9.1 image, as central runs), 1.3.0, 1.4.0, 1.5.0 and 1.6.0 (Cloudly 33.0.0, 33.1.0, 33.2.0 and 33.3.0 images). App Store 32.7.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • Merge the dashboard bundle's third-party notices into the release binaries' THIRD_PARTY_NOTICES.md. The binary embeds the minified dashboard bundle from dist_serve, whose packages' license texts it carried nowhere; @git.zone/tsbundle 3 writes them beside the bundle as dist_serve/bundle.js.third-party-notices.txt and .json. The release workflow's notices step now runs pnpm run notices:binary (scripts/assemble-binary-notices.ts), which writes the Onebox and @serve.zone/workloadinit licenses, the workloadinit notices, the dashboard notices verbatim in a fenced block and notices/third-party-notices.supplement.md. It refuses a build without the dashboard notices, a text file that is not tsbundle's, and a text and JSON pair that disagree on the bundled packages. test/binary-notices.node.ts covers the merge and the three refusals with fixture notices.
    • @design.estate/dees-catalog ^16.4.0 → ^16.6.0; release tooling @git.zone/tsbundle 3.0.0 (the dashboard bundle ships its third-party notices, which the binary notices now merge), @git.zone/tsdeno 1.11.0 (the committed minimumDependencyAge in deno.json stays authoritative) and @git.zone/tswatch 4.0.2 (pnpm 12.6.0 and @types/node 26.6.3 wait for the seven-day rule).
    Downloads
  • v32.17.0 2e83fbb5b4
    Compare

    v32.17.0
    Release / build-and-release (push) Failing after 10m53s
    Details
    Stable

    philkunz released this 2026-09-27 22:38:29 +00:00 | 8 commits to main since this release

    2026-09-27 - 32.17.0

    Features

    • Bundle the Cloudly App Store template 1.6.0 for Cloudly 33.3.0 through @serve.zone/appstore 32.6.0, moved from 32.5.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.6.0 on a host running template 1.2.1, 1.3.0, 1.4.0 or 1.5.0 needs this release. The template pins the Cloudly 33.3.0 image index code.foss.global/serve.zone/cloudly@sha256:fe1d10de09a8dc28f4dcf32b8e2cfed1ca7329b7d1b7405048a6e328afe5f9a6, keeps the 1.5.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0. It marks the upgrade breaking, migration-required, backup-before-upgrade and manual-review, because Onebox reads these flags from the target version alone: from 1.2.1 Cloudly still migrates its data forward only from 0.20.0 to 0.21.0 at the first start, and only the pre-upgrade backup goes back; from 1.4.0 and 1.5.0 there is no data step, but the template changelog names the service network egress settings, the database-endpoint-unselected and objectstorage-endpoint-unselected refusals and, from 1.4.0, the rollout order Cloudly 33.3.0 before Coreflow 33.2.0. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.6.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 (Cloudly 32.9.1 image, as central runs), 1.3.0, 1.4.0 and 1.5.0 (Cloudly 33.0.0, 33.1.0 and 33.2.0 images). App Store 32.6.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • Release tooling: @git.zone/tstest 6.3.2 and @git.zone/tsrun 3.0.1 (@types/node stays 26.6.2 until 26.6.3 clears the seven-day rule).

    • Move the dashboard to @serve.zone/catalog 33.0.0 (from 4.0.0) and @design.estate/dees-catalog 16.5.0 (from 10.0.0) in one step, with @design.estate/dees-element 3.3.0 (from the exact 3.0.0 pin, now ^3.3.0) in package.json and pnpm-lock.yaml, and @design.estate/dees-domtools 3.0.1 through them; catalog 33 requires dees-catalog 16, and a second copy of dees-catalog would register the same custom elements twice. pnpm dedupe moves dees-element's own dees-domtools from 3.0.0 to 3.0.1, so the bundle in dist_serve holds one copy each of dees-catalog, dees-element, dees-domtools and lit. The dashboard needed no source change: it does not use the app shell (dees-appui) whose 15.0.0 changes break hosts, nor dees-chart-area, and every property, event and method it binds on dees-simple-appdash, dees-simple-login, dees-table, dees-input-text, dees-tile, dees-button, DeesModal, DeesToast and DeesUpdater is unchanged; @serve.zone/catalog 32.0.0 and 33.0.0 change no sz-* element Onebox uses. What looks different comes from dees-catalog itself, for example dees-button's icon size and glyph inset (15.2.0), dees-simple-login without its own card border (13.5.0) and the xterm 6 based dees-chart-log in the service log views (14.0.0). All four packages are dashboard-only devDependencies, so they stay out of deno.lock and the binary's runtime graph; the binary grows by 3,238,976 bytes on both targets, almost all of it the larger dashboard bundle it embeds from dist_serve, to 553,573,176 bytes for x64 and 542,359,040 bytes for arm64, inside the size budgets. The browser render gate test/test.catalog-render.browser.ts now also requires the dees-* and sz-* elements the dashboard uses to be registered, which fails when a second catalog copy stops the bundle at a repeated customElements.define.

    • Guard every binary build with @git.zone/tsdeno 1.10.0, moved from 1.9.0 in package.json and pnpm-lock.yaml. .smartconfig.json pins denoVersion 2.9.4, so tsdeno refuses any other Deno before it compiles (and for tsdeno install), which replaces the deno eval version check build:binary ran first. Each target has a size floor, about 75 % of its built size: minSize 390 MiB for x64 and 385 MiB for arm64, because Deno 2.9 can exit 0 with a fraction of the binary when its npm downloads fail. After the size checks tsdeno runs the x64 binary once as onebox --version in an empty environment and requires exit code 0 and the @serve.zone/onebox v<version> line; the arm64 smoke check is skipped on an x64 builder as a foreign target. The move to tsdeno 1.10.0 alone leaves the binary sizes unchanged but for a few bytes; the release sizes are in the dees-catalog entry. Onebox stays on Deno 2.9.4: tsdeno 1.10.0 supports it, no Onebox defect is traced to it, and 2.9.7 would refuse the committed deno.lock, whose npm entries name the registry mirror's tarball URLs, so a move is its own change with a registry-neutral lock.

    Downloads
  • v32.16.1 5c94dd654e
    Compare

    Onebox v32.16.1
    Release / build-and-release (push) Successful in 33m14s
    Details
    Stable

    jkunz released this 2026-09-27 11:28:09 +00:00 | 11 commits to main since this release

    2026-09-27 - 32.16.1

    Maintenance

    • Bring release tooling current: @git.zone/tstest 6.3.1; pnpm 12.5.1 and @types/node 26.6.2 stay, because pnpm 12.6.0/12.7.0 and @types/node 26.6.3 are younger than the seven-day rule.

    • Compile leaner release binaries with @git.zone/tsdeno 1.9.0, moved from 1.8.0 in package.json and pnpm-lock.yaml. The x64 binary shrinks from 1,106,041,160 to 550,334,336 bytes and the arm64 binary from 1,097,396,616 to 539,120,200 bytes (both about −50 %). tsdeno 1.9.0 leaves out, per target, the native engines and platform packages built for other systems (x64 906,056,288 and arm64 885,026,216 bytes with that alone). The dashboard packages @design.estate/dees-catalog, @design.estate/dees-element, @serve.zone/catalog and @simplewebauthn/browser move to devDependencies: no server module imports them, and tsbundle bundles them into dist_serve at build time. The runtime-only manifest tsdeno compiles under therefore leaves dees-catalog, @serve.zone/catalog, @simplewebauthn/browser, the dashboard's dees-element 3.0.0 pin and the 79 other embedded packages only they need (monaco-editor, echarts, pdfjs-dist, the @napi-rs/canvas Skia addons, the tiptap and prosemirror editors and others, about 337 MiB) out of the binary (dees-element 3.1.1 stays, required by @push.rocks/taskbuffer and @push.rocks/smartntml); deno.lock, regenerated with tsdeno install, drops 92 entries (the removed packages plus their other-platform canvas builds) and changes no resolved version. Explicit rules leave out the unused debug server and debug UI folders of @lossless.org/nosqldb and @push.rocks/smartdb (9.1 MiB). Source maps stay embedded, so npm stack traces from a production binary remain readable. Each target has a size budget (maxSize 550 MiB for x64, 540 MiB for arm64) that fails the build on a regression. verify:binary no longer requires @serve.zone/catalog in the binary; it still checks the version, the Typed RPC self-test and every server-side package.

    Downloads
  • v32.16.0 d7c46ae34a
    Compare

    Onebox v32.16.0
    Release / build-and-release (push) Successful in 26m36s
    Details
    Stable

    jkunz released this 2026-09-26 20:51:35 +00:00 | 14 commits to main since this release

    2026-09-26 - 32.16.0

    Features

    • Bundle the Cloudly App Store template 1.5.0 for Cloudly 33.2.0 through @serve.zone/appstore 32.5.0, moved from 32.4.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.5.0 on a host running template 1.2.1, 1.3.0 or 1.4.0 needs this release. The template pins the Cloudly 33.2.0 image index code.foss.global/serve.zone/cloudly@sha256:11bc9a39011c1fa21bf621067e0ff6d4c2fe8cb0306745eca825db13285ae756, keeps the 1.4.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0. It marks the upgrade breaking, migration-required, backup-before-upgrade and manual-review, because Onebox reads these flags from the target version alone: from 1.2.1 Cloudly still migrates its data forward only from 0.20.0 to 0.21.0 at the first start, and only the pre-upgrade backup goes back; from 1.3.0 and 1.4.0 there is no data step, but the template changelog names the rollout order (Cloudly 33.2.0 before Coreflow 33.2.0, 33.1.0 of both at minimum) and, from 1.3.0, the per-node Corestore database endpoint without which a database binding is not granted. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.5.0 is the latest catalog version and prepares its upgrade from a 1.2.1 install running the Cloudly 32.9.1 image, as central does, from a 1.3.0 install running the Cloudly 33.0.0 image and from a 1.4.0 install running the Cloudly 33.1.0 image. App Store 32.5.0 still pins @serve.zone/interfaces 32.3.0, so no other package moves.
    Downloads
  • v32.15.0 97c68fcf30
    Compare

    Onebox v32.15.0
    Release / build-and-release (push) Successful in 27m16s
    Details
    Stable

    jkunz released this 2026-09-26 12:27:20 +00:00 | 16 commits to main since this release

    2026-09-26 - 32.15.0

    Features

    • Bundle the Cloudly App Store template 1.4.0 for Cloudly 33.1.0 through @serve.zone/appstore 32.4.0, moved from 32.3.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.4.0 on a host running template 1.2.1 or 1.3.0 needs this release. The template pins the Cloudly 33.1.0 image index code.foss.global/serve.zone/cloudly@sha256:15796a1a784652cc8a59020125db14dc833c7e0e12d584209ccd6ada8f302bff, keeps the 1.3.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0. It marks the upgrade breaking, migration-required, backup-before-upgrade and manual-review, because Onebox reads these flags from the target version alone: from 1.2.1 Cloudly still migrates its data forward only from 0.20.0 to 0.21.0 at the first start, and only the pre-upgrade backup goes back; from 1.3.0 there is no data step, but the template changelog names the Cloudly 33.1.0 rollout order (Cloudly, then Coreflow 33.1.0, then Corestore 33.0.0) and the per-node Corestore database endpoint without which a database binding is not granted. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now checks that 1.4.0 is the latest catalog version and prepares its upgrade from a 1.2.1 install running the Cloudly 32.9.1 image, as central does, and from a 1.3.0 install running the Cloudly 33.0.0 image. App Store 32.4.0 still pins @serve.zone/interfaces 32.3.0, so no other package moves.
    Downloads
  • v32.14.0 ad2823066f
    Compare

    Onebox v32.14.0
    Release / build-and-release (push) Successful in 26m55s
    Details
    Stable

    jkunz released this 2026-09-26 08:48:02 +00:00 | 18 commits to main since this release

    2026-09-26 - 32.14.0

    Features

    • Bundle the Cloudly App Store template 1.3.0 for Cloudly 33.0.0 through @serve.zone/appstore 32.3.0, moved from 32.2.0 in package.json, pnpm-lock.yaml and the binary's deno.lock. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.3.0 on a host running template 1.2.1 needs this release. The template pins the Cloudly 33.0.0 image index code.foss.global/serve.zone/cloudly@sha256:26a7469181059aca2a5505d2f86e8f6286ebc0b1e0dee0df2262bfe3df2d1f06, keeps the 1.2.1 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0. It marks the upgrade breaking, migration-required, backup-before-upgrade and manual-review: Cloudly 33.0.0 migrates its data from 0.20.0 to 0.21.0 at the first start, retiring its Cloudflare and Let's Encrypt integration, and only the pre-upgrade backup goes back. Onebox enforces only minOneboxVersion; the other flags and the template changelog are the operator's, as the Cloudly upgrade runbook states. The App Store upgrade test now prepares the 1.2.1 to 1.3.0 upgrade of an install running the Cloudly 32.9.1 image, as central does. App Store 32.3.0 still pins @serve.zone/interfaces 32.3.0, so no other package moves.

    Maintenance

    • Bring the release-time tooling current: pnpm 12.5.0 → 12.5.1, @git.zone/tstest 6.2.1 → 6.3.0 and @types/node 26.6.1 → 26.6.2; pnpm 12.6.0 and @types/node 26.6.3 are still inside the seven-day window, and the other @git.zone tools are current. tstest 6.3.0 needs no migration. pnpm dedupe leaves one @types/node 26 in the tree.
    Downloads
  • v32.13.1 92df0cdcca
    Compare

    Onebox v32.13.1
    Release / build-and-release (push) Successful in 22m36s
    Details
    Stable

    jkunz released this 2026-09-25 19:43:36 +00:00 | 21 commits to main since this release

    2026-09-25 - 32.13.1

    Fixes

    • Refuse a backup or restore that needs the Docker CLI by name when the host has none, instead of failing midway with spawn docker ENOENT. Onebox reaches the Docker daemon through its API client, but reads volumes with docker cp, exports the image with docker save and restores both with docker cp and docker load, so the CLI is a host requirement for those backups. A backup of a service with volumes or an included image is now refused as docker-cli-missing before it reads anything, and a restore of such a backup before it stages anything; every Docker CLI step runs the executable resolved from an absolute PATH entry and names, with --host, the socket Onebox's Docker API client connects to, so neither DOCKER_HOST nor a Docker CLI context can send a backup or restore to another daemon than the one Onebox manages. The release workflow installs a pinned, checksum-verified Docker CLI and proves it reaches the daemon, since its base image ships none, which failed the v32.13.0 release in the volume backup test.

    Maintenance

    • Bring the release-time tooling current: pnpm 12.4.2 → 12.5.0 (the newest release older than seven days) and @git.zone/tstest 6.2.0 → 6.2.1; the other @git.zone tools are current; @types/node stays 26.6.1 by the seven-day rule.
    Downloads
  • v32.12.0 ed9f0e6bba
    Compare

    Onebox v32.12.0
    Release / build-and-release (push) Successful in 29m34s
    Details
    Stable

    jkunz released this 2026-09-25 15:04:43 +00:00 | 27 commits to main since this release

    2026-09-25 - 32.12.0

    Features

    • Make the SMB storage target password write-only instead of storing and returning it in the clear. The password is no longer part of the target configuration: it is set with the new setStorageTargetPassword request, stored with Onebox's credential encryption, and every response reports only passwordSet. getStorageConfig and upsertStorageTarget return no password, the settings dialog no longer pre-fills it, and a configuration that still contains one is refused. Changing an SMB target's server, share or kind removes the stored password.
    • Give every volume on an NFS or SMB target an explicit subPath below the target's root. The data version moves to 0.25.0 through the step storage-target-credentials, which encrypts stored SMB passwords, rewrites every existing network volume to subPath: "." (the root it already mounts, so no data moves), and removes credential elements from other stored volume options. A request may name another subPath, which must exist on the export; a volume keeps its subPath across updates. Restoring a backup from an earlier release drops the mount options it recorded for such a volume. The step is one-way: Onebox releases up to 32.11.0 know data versions only up to 0.24.0 and refuse a 0.25.0 ledger by name, so going back to 32.11.0 after the upgrade needs a database copy taken before it; without one, recovery is forward-only.

    Fixes

    • Stop copying a volume's resolved mount options onto the service record. A volume on an NFS or SMB target is stored as its storage class and subPath; its mount, with the decrypted password, is composed only when Onebox creates the runtime. Onebox creates such a Docker volume before the runtime and mounts it by name, so container and Swarm service specifications no longer carry the password. Docker's local volume driver keeps it in the volume's options: it mounts with mount(2), and the kernel ignores credentials=, so there is no credentials file it can read instead.
    • Refuse storage target values that could add mount options. The server, username, domain, password and every option value of an NFS or SMB target are refused when they contain a comma or a control character, option keys are limited to letters, digits, dots, dashes and underscores, and options may not restate the address, version or identity the target states. Refusals are reported as storage-target-config-invalid and name the field, never the value. Storage targets now have one typed configuration per kind, and a member the kind does not have is refused.
    • Backups and database copies from earlier releases contain the SMB password in the clear; change it on the SMB server after upgrading and set the new one on the target.
    Downloads