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

78 Releases 301 Tags

RSS Feed
  • v33.6.0 968f53dfa2
    Compare

    Onebox v33.6.0
    Release / build-and-release (push) Failing after 44m22s
    Details
    Stable

    philkunz released this 2026-10-04 07:37:54 +00:00 | 34 commits to main since this release

    2026-10-04 - 33.6.0

    Features

    • Bundle the Cloudly App Store template 1.17.0 for Cloudly 33.13.4 through @serve.zone/appstore 32.17.0, moved from 32.16.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.17.0 needs this release. The template pins the Cloudly 33.13.4 image index code.foss.global/serve.zone/cloudly@sha256:b1846a07c9818b5e77f4fd39951256088b3f57101b64695db7aa7ca35eb5ef5c and keeps the 1.16.0 runtime contract, minOneboxVersion 32.4.0 and upgrade flags; against 1.16.0 only its image and changelog differ. Cloudly 33.13.4 delivers the secret material of a run started through the WorkloadInit launcher again (Cloudly compared the run's pinned artifact with the approved one as JSON strings, so every launcher-delivered run's material, Corestore's MONGODB_URI included, was denied; it now compares the platform and both digests), remembers a successful WorkloadInit approval verification of an active artifact by its SHA-256 so a material request no longer waits for a registry verification each time, and answers a refused material request with { code: 'runtime-session-report-refused', reason }, a closed, value-free reason; since Cloudly 33.13.3 a node's session is pushed once per assignment revision instead of on every delivery pass. Cloudly 33.13.3 and 33.13.4 keep the data version 0.24.0, so an upgrade from 1.16.0 runs no data step. From 1.15.0 and every earlier template Cloudly still runs the forward-only 0.23.0 to 0.24.0 step corestore-control-token-state at its first start, after the earlier steps the older installs need, and every earlier Cloudly refuses the migrated data (DOWNGRADE_NOT_SUPPORTED), so stop Cloudly and take a verified backup (onebox backup create cloudly) before upgrading; a rollback is onebox backup restore <backup-id> of that backup, not an App Store downgrade, which the forward-only catalog gate refuses anyway. Hosts read the migration-required, backup-before-upgrade, breaking and manual-review flags from the target version alone, so they stay set for every source version, and the template names the rollout order Cloudly 33.13.4 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.17.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 through 1.16.0, the latter on the Cloudly 33.13.2 image. App Store 32.17.0 keeps @serve.zone/interfaces 32.42.0, so no other serve.zone package moves. deno.lock was re-resolved from https://registry.npmjs.org/ after a build (505 packages, every one pinned by SHA-512, no tarball URL) and changes only the App Store entry. In pnpm-lock.yaml the install also moved the test-only containerarchive-legacy-index alias (@serve.zone/containerarchive 0.6.2) from @push.rocks/lik 6.4.2 to 6.4.4, a version already in the tree, so no package enters or leaves it; no entry was rewritten to SHA-1.
    Downloads
  • v33.5.0 43a53d19e7
    Compare

    Onebox v33.5.0
    Release / build-and-release (push) Failing after 27m52s
    Details
    Stable

    philkunz released this 2026-10-03 16:32:55 +00:00 | 36 commits to main since this release

    2026-10-03 - 33.5.0

    Features

    • Bundle the Cloudly App Store template 1.16.0 for Cloudly 33.13.2 through @serve.zone/appstore 32.16.0, moved from 32.15.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.16.0 needs this release. The template pins the Cloudly 33.13.2 image index code.foss.global/serve.zone/cloudly@sha256:e97c7768f845494b6d269709e56fccf6178519910d70ed3877a1368f3976e3d0 and keeps the 1.15.0 runtime contract and minOneboxVersion 32.4.0; against 1.15.0 only its image and changelog differ. Cloudly 33.11.0 moves the data version from 0.23.0 to 0.24.0: from 1.15.0 and every earlier template Cloudly runs the forward-only data step corestore-control-token-state at its first start, which records a Corestore control token stored before 33.11.0 as revision 1, after the earlier steps the older installs need (from 1.8.0 and earlier deployment-machine-user-grants from 0.22.0 to 0.23.0, from 1.6.0 and earlier runtime-session-protocol-offer from 0.21.0 to 0.22.0, and from 1.2.1 the 0.20.0 to 0.21.0 migration of Cloudly 33.0.0). The step has no inverse and every earlier Cloudly refuses the migrated data (DOWNGRADE_NOT_SUPPORTED), so stop Cloudly and take a verified backup (onebox backup create cloudly) before upgrading; a rollback is onebox backup restore <backup-id> of that backup, not an App Store downgrade, which the forward-only catalog gate refuses anyway. The migration-required, backup-before-upgrade, breaking and manual-review flags of the template therefore now hold for every source version, and it names the rollout order Cloudly 33.13.2 before Coreflow 33.2.0. Cloudly 33.11.0 through 33.13.2 let an administrator set the Corestore control token without an exec into Cloudly's container (setCorestoreControlToken, getCorestoreControlTokenState, servezone corestore set-control-token), retire a cluster node (retireClusterNode), keep a node's VPN membership across a protected-authority step that only adds, and keep the lease of a stopping workload until the node's stop receipt; the collections they need (Corestore control token state and receipts, node retirement rows and admissions, egress retirements, runtime slot abandonments) Cloudly installs at startup. From 1.14.0 or earlier the Cloudly 33.10.0 relay bearer export applies too. 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.16.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 through 1.15.0, the latter on the Cloudly 33.10.0 image. App Store 32.16.0 keeps @serve.zone/interfaces 32.42.0, so no other serve.zone package moves. deno.lock was re-resolved from https://registry.npmjs.org/ after a build (505 packages, every one pinned by SHA-512, no tarball URL); besides the App Store it only marks @push.rocks/consolecolor 2.0.4, @push.rocks/smartdelay 3.1.0, @push.rocks/smarthash 3.3.0 and @push.rocks/webrequest 4.3.1 deprecated at unchanged versions, as the registry now reports them. In pnpm-lock.yaml the install also folded two development-only duplicates: @git.zone/tsdeno now resolves the project's @git.zone/tsbundle 3.1.3, so @git.zone/tsbundle 2.15.0, 3.1.0 and 3.1.2 and @push.rocks/smartcli 4.3.1 and 5.0.1 leave the tree, and the test-only containerarchive-legacy-index alias resolves @push.rocks/smartpromise 4.3.0; no entry was rewritten to SHA-1.

    Maintenance

    • Release tooling: @git.zone/tstest 7.1.0 (from 6.3.4; its breaking change, TapNodeTools.runCommand() output, is unused here), @git.zone/tswatch ^6.0.1 (from ^5.0.1; Onebox already builds with tsbundle 3), @git.zone/tsbuild ^5.1.2, @git.zone/tsbundle ^3.1.3 and @types/node 26.6.3; pnpm 12.7.0 and @git.zone/tsdeno ^1.14.1 are already current, and @types/node stays below 26.6.4 until it is seven days old.
    Downloads
  • v33.4.0 ea214ece09
    Compare

    Onebox v33.4.0
    Release / build-and-release (push) Failing after 19m38s
    Details
    Stable

    philkunz released this 2026-10-02 14:20:15 +00:00 | 40 commits to main since this release

    2026-10-02 - 33.4.0

    Features

    • onebox runtime status [--json] reports every service and platform workload as its runtime backend sees it: backend, recorded and runtime state, health, desired and running replicas, image reference and pinned digest, and the runtime ids (on Docker the Swarm service or container id and the ids of the containers that run it). --json prints one IOneboxRuntimeStatusReport (ts_interfaces/data/runtime.ts) and nothing else, so scripts read the runtime through Onebox instead of docker service inspect or docker service ps. The command runs in the daemon and changes nothing; the CoreTraffic and managed dcrouter workloads are not part of it. Each runtime backend states its name and observes a workload through the new observeWorkload() of the runtime seam.

    • Workloads reach the Onebox host by a runtime-neutral host endpoint the runtime backend supplies (getHostEndpointName()), host.onebox.internal on the Docker backend, which maps it to Docker's host gateway. A hosted app's SERVEZONE_RUNTIME_URL is now http://host.onebox.internal:3000 (a SERVEZONE_RUNTIME_URL or ONEBOX_RUNTIME_URL in the daemon's environment still takes precedence), and the Admin UI route targets the host endpoint when serverIP is unset, where it named host.docker.internal. A hosted app deployed before keeps http://host.docker.internal:3000 until its next update (App Store upgrade, service patch-env, service set-secret or any other replacement) writes the host endpoint URL; nothing is redeployed for it, and the Docker backend keeps resolving host.docker.internal for service workloads until then.

    • Bundle the Cloudly App Store template 1.15.0 for Cloudly 33.10.0 through @serve.zone/appstore 32.15.0, moved from 32.14.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.15.0 needs this release. The template pins the Cloudly 33.10.0 image index code.foss.global/serve.zone/cloudly@sha256:a49aa0a4f7b312656786f0d4b303cb40e25e766b98c778c83790948de43062be and keeps the 1.14.0 runtime contract and minOneboxVersion 32.4.0; against 1.14.0 only its image and changelog differ. Cloudly 33.10.0 lets an administrator export a cluster relay's bearer through exportClusterRelayAuthorization with an audit receipt in the new collection cloudly_cluster_relay_authorization_exports, which Cloudly installs at startup; from 1.14.0 or earlier the Cloudly 33.9.0 changes apply too (a node's managed VPN member kept across projection changes, stored failure causes of failed runs, deleteServiceById success while another deletion drains and its named refusals). It keeps the data version 0.23.0, so from 1.9.0 through 1.14.0 nothing migrates; the template still marks the upgrade migration-required, backup-before-upgrade, breaking and manual-review, because hosts read these flags from the target version alone, and names the rollout order Cloudly 33.10.0 before Coreflow 33.2.0. The App Store upgrade test now checks that 1.15.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 through 1.14.0, the latter on the Cloudly 33.8.3 image. App Store 32.15.0 pins @serve.zone/interfaces 32.42.0 exactly, where 32.14.0 pinned 32.3.0, so Onebox's own pin moves from 32.40.1 to 32.42.0 with it and @serve.zone/api from 32.3.1 to 32.4.0 (interfaces 32.41.0 and its relay bearer export client; Onebox still uses only CoreMailControlClient); interfaces 32.41.0 and 32.42.0 add contracts Onebox does not use (relay bearer export, Corestore control token, egress owner retirement, protected-authority successors). The interfaces 32.3.0 copy and its @push.rocks/smartcrypto 2 leave the App Store's dependency path. deno.lock was re-resolved from https://registry.npmjs.org/ after a build (505 packages, every one pinned by SHA-512, no tarball URL); besides the three serve.zone packages it moves @push.rocks/smartlog 4.0.0 to 4.0.3 and @push.rocks/smartrequest 5.5.1 to 5.6.0 and adds @push.rocks/smartconsole 2.0.1 with its terminal-width dependencies.

    Fixes

    • Swarm service workloads resolve the host names Onebox gives them. Onebox wrote the Swarm Hosts entry as host.docker.internal:host-gateway, the format of a container's extra hosts; Swarm reads Hosts in the hosts(5) form <address> <name> and drops an entry without whitespace, so the name never reached a task container and a Swarm-run hosted app could not resolve the host of its SERVEZONE_RUNTIME_URL. Service workloads now carry host-gateway host.onebox.internal and host-gateway host.docker.internal; a running service picks them up when it is next replaced. The CoreTraffic workload carries host-gateway host.onebox.internal, so the Admin UI route without serverIP resolves; this changes CoreTraffic's specification, so the first start after the upgrade replaces the CoreTraffic service once, as a CoreTraffic image change does.

    Maintenance

    • @push.rocks/smartjwt moves from ^2.2.2 to ^3.0.0 and the direct @push.rocks/smartcrypto pin from 2.2.0 to 3.0.0, which drop node-forge (GHSA-86w9-cpqp-85rv). Onebox uses smartjwt only to create and verify the dashboard's session JWTs with a key pair it generates at every start, and smartcrypto only for the App Store secret-ingress X25519 envelopes (generateX25519KeyPair, sealX25519Envelope, openX25519Envelope, SMARTCRYPTO_X25519_KEY_BYTES), whose API 3.0.0 keeps; nothing used the removed RSA forge surface. @serve.zone/interfaces moves from 32.36.1 to 32.40.1 (smartcrypto 3, and runtime session and Pallet projection contracts Onebox does not use) and @serve.zone/api from 32.0.0 to 32.3.1 (smartcrypto 3 and interfaces 32.40.1; Onebox uses only its CoreMailControlClient). The moves are in package.json, pnpm-lock.yaml and the binary's deno.lock; the eight pnpm-lock.yaml entries the install rewrote to SHA-1 keep their npmjs SHA-512 integrity at unchanged versions. node-forge stays in the production tree through @serve.zone/corestore 34.0.0 (smartjwt 2, interfaces 32.36.1) and acme-client 5.4.0 (through @push.rocks/smartdns 8, which @push.rocks/smartacme 10 and @apiclient.xyz/docker 10.1.2 through @push.rocks/smartnetwork 4 bring); the App Store's path left with @serve.zone/appstore 32.15.0 (see Features).
    • Release tooling: @git.zone/tsbuild ^5.1.1, @git.zone/tsbundle ^3.1.2, @git.zone/tsdeno ^1.14.1, @git.zone/tstest 6.3.4, @git.zone/tswatch ^5.0.1 and pnpm 12.7.0; @types/node stays 26.6.2. tsbuild, tsbundle, tsdeno and tswatch now parse their CLIs with @push.rocks/smartconsole 2, which refuses unknown commands and options and accepts only true/false for declared boolean options; every invocation in package.json and the release workflow, including tsdeno install --entrypoint --frozen --lock=deno.lock binary/onebox.ts and the documented deno.lock regeneration, runs unchanged, and the regeneration under tsdeno 1.14.1 reproduces the committed deno.lock byte for byte. tswatch 5's breaking change concerns only its programmatic init API, which Onebox does not use. tstest 6.3.3 and 6.3.4 drop node-forge from tstest itself; TapNodeTools.createHttpsCert(), whose key PEM changed to PKCS#8, is not used here. The two pnpm-lock.yaml entries the install rewrote to SHA-1 (ansi-256-colors 1.1.0 and boolbase 1.0.0) keep their npmjs SHA-512 integrity at unchanged versions.
    Downloads
  • v33.3.0 3edf3dd738
    Compare

    Onebox v33.3.0
    Release / build-and-release (push) Failing after 12m37s
    Details
    Stable

    philkunz released this 2026-10-01 21:21:41 +00:00 | 44 commits to main since this release

    2026-10-01 - 33.3.0

    Features

    • Bundle the Cloudly App Store template 1.14.0 for Cloudly 33.8.3 through @serve.zone/appstore 32.14.0, moved from 32.13.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.14.0 needs this release. The template pins the Cloudly 33.8.3 image index code.foss.global/serve.zone/cloudly@sha256:0925a1f053899655ec039a7751f51a640f7fc14e458a58d9f5a3e43f04ca9a9f and keeps the 1.13.0 runtime contract and minOneboxVersion 32.4.0; against 1.13.0 only its image and changelog differ, and the package changes nothing else. Cloudly 33.8.3 can retire a legacy service whose Corestore resources a successor adopted, refuses its deletion with SERVICE_LEGACY_IMPORT_PENDING while a legacy import of its attestations is pending, deletes the attestations no release consumed when a deletion proceeds, and serializes import and deletion on the registry repository. It keeps the data version 0.23.0, so from 1.9.0 through 1.13.0 nothing migrates; the template still marks the upgrade migration-required, backup-before-upgrade, breaking and manual-review, because hosts read these flags from the target version alone, and names the rollout order Cloudly 33.8.3 before Coreflow 33.2.0. The App Store upgrade test now checks that 1.14.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 through 1.13.0, the latter on the Cloudly 33.8.2 image. App Store 32.14.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.
    Downloads
  • v33.2.0 b2aab76d45
    Compare

    Onebox v33.2.0
    Release / build-and-release (push) Failing after 12m49s
    Details
    Stable

    philkunz released this 2026-10-01 15:41:06 +00:00 | 46 commits to main since this release

    2026-10-01 - 33.2.0

    Features

    • Bundle the Cloudly App Store template 1.13.0 for Cloudly 33.8.2 through @serve.zone/appstore 32.13.0, moved from 32.12.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.13.0 needs this release. The template pins the Cloudly 33.8.2 image index code.foss.global/serve.zone/cloudly@sha256:ae11ddffd91351b33d34c72785f8372241c1ae8c47a5cf31ef79061bc37a2e5c and keeps the 1.12.0 runtime contract and minOneboxVersion 32.4.0; against 1.12.0 only its image and changelog differ, and the package changes nothing else. Cloudly 33.8.2 logs a refused node report once per node, report and distinct reason and answers it with the unchanged error text plus { code: 'runtime-session-report-refused', reason }. It keeps the data version 0.23.0, so from 1.9.0 through 1.12.0 nothing migrates; the template still marks the upgrade migration-required, backup-before-upgrade, breaking and manual-review, because hosts read these flags from the target version alone, and names the rollout order Cloudly 33.8.2 before Coreflow 33.2.0. The App Store upgrade test now checks that 1.13.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 through 1.12.0, the latter on the Cloudly 33.8.1 image. App Store 32.13.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • Release tooling: @git.zone/tswatch 4.1.0.
    Downloads
  • v33.1.1 2574cf1857
    Compare

    Onebox v33.1.1
    Release / build-and-release (push) Failing after 11m18s
    Details
    Stable

    philkunz released this 2026-09-30 09:01:20 +00:00 | 49 commits to main since this release

    2026-09-30 - 33.1.1

    Fixes

    • pnpm run notices:binary and pnpm run check:binary-notices find the server-side packages in Deno's npm cache again. Since deno.lock records no tarball URL, scripts/binary-notices.ts looked for mariadb, denque, lru-cache and @clickhouse/client below registry.npmjs.org, while Deno files them below the host of the registry the project's .npmrc names, so the notices of a v33.1.0 build failed with "The embedded package mariadb is not in Deno's npm cache". The notices and binary/verify-runtime-cache.mjs now read the registry through one module, binary/npm-registry.mjs, which refuses an .npmrc that names anything but one bare HTTPS registry origin and an npm registry environment that disagrees with it. The release workflow's notices step now uses the pinned Deno 2.9.7 and the DENO_DIR the binary was compiled from ($HOME/.deno-dir-release); it ran with the runner's default Deno cache. v33.1.0 has no Gitea release; 33.1.1 is the first release that publishes the per-target third-party notices beside the binaries.
    Downloads
  • v33.0.0 38048c65df
    Compare

    Onebox v33.0.0
    Release / build-and-release (push) Failing after 11m14s
    Details
    Stable

    philkunz released this 2026-09-29 23:59:49 +00:00 | 55 commits to main since this release

    2026-09-29 - 33.0.0

    Breaking Changes

    • The package's Docker manager is the Docker runtime backend now, with no aliases: the export OneboxDockerManager is DockerRuntimeBackend (with the IOneboxRuntimeBackend type beside it), Onebox.docker is Onebox.runtime for every workload effect and Onebox.dockerRuntime and Onebox.corestoreEngineDocker for the Docker-only Corestore conversion steps. DockerImageLoadError is gone: images no longer travel through the runtime (see below).
    • A backup that includes the service's image reads it from the registry the service pulled it from, no longer from the runtime (docker save). The registry must be reachable with the credentials Onebox holds for it and must still serve the image the service runs; an image that was only ever built on the host is refused by name as backup-image-unavailable and must be pushed to a registry first. A restored image runs from Onebox's local registry (onebox-restore/<service>@sha256:…, with the local registry as the service's registry) instead of by its bare image ID.

    Features

    • Route every workload effect through one runtime seam, the first step of running Onebox on Pallet without Docker. IOneboxRuntimeBackend (ts/classes/runtime-backend.ts) states what Onebox needs from a runtime: service and platform workloads, their images, secrets, volumes, published ports, logs, stats and exec, the image and volume artifacts of a backup, the CoreTraffic ingress and managed dcrouter workloads, and the host prerequisites onebox systemd enable installs. Services, platform providers, WorkloadInit approvals, backups and the ops handlers now call only onebox.runtime. DockerRuntimeBackend (the former OneboxDockerManager, ts/classes/docker.ts) implements it on the Docker Engine API and Swarm, with the Docker parts of CoreTraffic (docker-coretraffic.ts), the managed dcrouter (docker-dcrouter.ts), Docker installation and swarm init (docker-host.ts) and the backup's docker save, docker load and docker cp steps (DockerArtifactTools in utils/docker-cli.ts) behind it. The Corestore engine conversion, its target handoffs, its data relocation and its maintenance containers are Docker history and move to CorestoreEngineDockerRuntime in ts_migration/corestore-engine-docker.ts; they and the other Corestore migrations reach Docker through onebox.corestoreEngineDocker and onebox.dockerRuntime. The seam states no Docker shapes: a service workload is created stopped with { start: false }, an interactive session reports { running, exitCode }, and a service runtime's secret files carry numeric owner ids, which the Docker backend reads from Swarm's decimal strings and refuses by name when one is not a canonical decimal. Otherwise nothing changes in behaviour: the same Docker requests, CLI commands, unit file and messages.
    • Administer MariaDB and ClickHouse over their own protocols, from the host, instead of running their command-line clients inside the platform containers: the first slice of taking exec off the paths that need no dump. Provisioning, deprovisioning and the MariaDB health check connect as the admin user through @lossless.org/client/sqldb (ts/classes/platform-services/sql-admin.ts) to the port the workload publishes on the host's loopback (getContainerHostPort), and the ClickHouse health check asks its HTTP /ping there. MariaDB binds no parameter in an account statement, so a user is created with IDENTIFIED BY PASSWORD and the mysql_native_password hash of its password, which is what MariaDB stores for IDENTIFIED BY '<password>'; ClickHouse takes the new password as a query parameter. No password reaches a command line, a process environment or a statement text, and a failure names only the client's error code and the engine's code, never the engine's message. Database dumps and restores still run inside the containers.
    • Back up and restore a service's image through registries instead of the runtime, so a backup no longer needs the runtime to export or import images (ts/classes/backup-image.ts). The backup fetches the image over the registry protocol (oci-registry-client.ts) by the service's canonical digest reference or else its configured reference, keeps the first whose index, manifest or config digest is the image ID the runtime reports, and stores it as an OCI image layout with the host platform's manifest, config and layers, each blob verified against its digest as it streams (oci-image-archive.ts); docker load reads that layout too. A restore reads an OCI image layout, or the docker-archive of a docker save from Docker before 25, which it converts into an OCI image over the same config and layer bytes after checking each layer against the diff ID its config records; it requires the archive to name the recorded image ID, pushes the image into the local registry under onebox-restore/<service> with the tag restored-<12 hex digits> (local-registry-image.ts) and has the runtime pull it by digest. Backups and restores of a service without volumes no longer need the Docker CLI. The runtime's artifact tools carry only volumes now (exportImage, importImage and their docker save/docker load steps are removed).
    • The dashboard runs in the dees-appui shell with path URLs: Overview; Workloads (Services, App Store); Domains & Traffic (Domains, DNS, Proxy); Registry (Registry, Tokens); Access; Settings pinned at the bottom. The server's own paths (/typedrequest, /oidc, /.well-known, /v2, /backups, /mcp) stay the server's. The update notice lives in the bottom bar and sign-out in the profile menu. Old dashboard URLs such as /apps/services open the not-found screen with a link to the Overview.
    • Every page has one header (title, one-line description, actions on the right) and one loading, empty and error pattern; duplicate headings are gone. Views load when they are shown and stop polling, live logs and metrics when they are left.
    • Services and platform services open as routed detail pages (/services/<name>, /platform-services/<type>) on @serve.zone/catalog 34's service detail page; every status reads from the platform's shared status vocabulary.
    • The overview shows compact figures and a "Needs attention" list: Docker down, proxy failed, CoreTraffic takeover failure and last refused route set, failed services and platform services, expired and expiring certificates, and missing gateway permissions.
    • Settings is split into Admin UI, Gateway, Storage, Platform and Updates (/settings/<section>); Access lists users and hosted-app sign-in in tables with "Invite user" in the page header.
    • Bundle the Cloudly App Store template 1.11.0 for Cloudly 33.8.0 through @serve.zone/appstore 32.11.0, moved from 32.10.0 in package.json, pnpm-lock.yaml and the binary's deno.lock, changing no other package's integrity and keeping the lock's registry origin. Onebox reads the App Store from the catalog this package bundles, so onebox appstore upgrade cloudly --version 1.11.0 needs this release. The template pins the Cloudly 33.8.0 image index code.foss.global/serve.zone/cloudly@sha256:06ab9a594aecf496fcc16f19bb19fd19123601e11f9615c0d5dcc9be9e540eda and keeps the 1.10.0 runtime contract and minOneboxVersion 32.4.0; against 1.10.0 only its image and changelog differ. Cloudly 33.8.0 adds no data step and keeps the data version 0.23.0, so from 1.9.0 or 1.10.0 nothing migrates; the template still marks the upgrade migration-required, backup-before-upgrade, breaking and manual-review, because hosts read these flags from the target version alone and every upgrade from 1.8.0 or earlier runs the forward-only data step deployment-machine-user-grants. Deploy Cloudly 33.8.0 before any Pallet that captures workload output reaches a fleet node, since it answers reportRuntimeAssignmentLogs with not-kept; from 1.4.0 and earlier roll out Cloudly 33.8.0 before Coreflow 33.2.0. The App Store upgrade test now checks that 1.11.0 is the latest catalog version and prepares its upgrade from installs of 1.2.1 through 1.10.0, the latter on the Cloudly 33.7.0 image. App Store 32.11.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Fixes

    • Security: close the local registry's storage server to everyone but the registry. The S3-compatible storage server that holds the registry's blobs, manifests and tags listened on 0.0.0.0:4000 and checked no credentials, so anyone who reached that port could read, overwrite and delete registry data, image layers included, without a /v2/token grant. It now listens on 127.0.0.1:4000 only and refuses every request without a SigV4 signature from a credential RegistryManager generates at each start and passes to its in-process smartregistry, the server's only client; the credential exists only in memory, never on disk or in a log (ts/classes/registry.ts). Registry data stays where it is, so an existing install needs no migration: the next start binds the new address and credential. A test proves the port refuses connections on a non-loopback interface, anonymous reads, writes and deletes, and the old fixed onebox credential, while the registry still stores and serves images (test/registry-storage-access.node.ts).
    • Stop the local registry's storage server again when the registry fails to initialize after starting it. RegistryManager.init() left the storage server running and the registry uninitialized when smartregistry's own initialization failed, for example when the storage server could not give it its bucket, so the storage port stayed bound and every later init() failed with Address already in use. A failed init() now closes the smartregistry instance and stops the storage server it started before it rethrows, so the same registry can initialize again (ts/classes/registry.ts). A test fails the initialization with a regular file in the place of the registry's bucket directory, then checks that the port is free and that the same registry initializes on it once the file is gone (test/registry-init.node.ts).
    • Security: @push.rocks/smartregistry moves from 2.10.1 to 2.11.2, which holds the local registry's OCI tokens to what Onebox issues: it compares a token's HS256 signature in constant time, refuses any other algorithm, a missing or non-numeric exp and a non-numeric nbf, requires iss to be the configured realm and aud to name the configured service, and refuses every OCI token while the OCI token service is disabled. Onebox mints its tokens through smartregistry's createOciToken() with OCI tokens enabled, so they carry exactly these claims and keep validating. The registry now shuts down through SmartRegistry.close(), which 2.11.0 added and which also releases the object storage client that destroy() left open (ts/classes/registry.ts). 2.11 stores through @lossless.org/client instead of @push.rocks/smartbucket and no longer needs @push.rocks/qenv or adm-zip; it brings no package Onebox did not already resolve. The move is in package.json, pnpm-lock.yaml and the binary's deno.lock, changing no other package's integrity and keeping the lock's registry origin.
    • Make Onebox's local registry usable by Docker and other OCI clients. Its Bearer challenge named a token endpoint (/v2/token) nothing served, and the registry tokens administrators create were never checked, so no client could pull from or push to it. /v2/token now issues a signed token, valid 300 seconds, for the requested repository actions the presented HTTP Basic credentials allow (ts/classes/registry-token-service.ts): a stored registry token (compared by SHA-256 in constant time, refused once expired) may push and pull the repositories its scope names, and an internal credential Onebox issues for each of its own runtime's pulls from the local registry may pull every repository and expires after ten minutes; the runtime's registry-auth hook hands that credential for the local registry. Two more defects kept clients out: the registry's OCI base path was empty, so every repository name began with v2/ and matched neither tokens nor tag storage (now /v2), and every response body smartregistry streams, blobs among them, was answered as the text {} (a stream now passes through). Tests drive the endpoint over HTTP against smartregistry and its storage server, and the local Docker daemon pulls from it by digest with an internal credential.
    • Authenticate every pull from a private registry. @apiclient.xyz/docker up to 10.1.1 sent the X-Registry-Auth header as unpadded base64url, which the Docker daemon cannot decode and then pulls anonymously without an error: the credentials Onebox holds for a registry reached the daemon only when their JSON length was a multiple of three, about one pull in three, so a private image otherwise failed with an access error. 10.1.2 pads the header. @apiclient.xyz/docker moves from 10.1.1 to 10.1.2 in package.json, pnpm-lock.yaml and the binary's deno.lock, changing no other package's integrity and keeping the lock's registry origin; regenerating deno.lock for it resolves @push.rocks/smartarchive 5.5.1 (with file-type 22.1.1), which @apiclient.xyz/docker requires as ^5.4.1, where pnpm-lock.yaml keeps 5.4.1. No Onebox code changes with it.
    • A sign-in page that cannot reach Onebox says so ("Onebox is not reachable") with Retry and the technical detail folded away, instead of asking for a trusted hostname and showing the raw exception; every sign-in and hosted-app sign-in error is a sentence.
    • Deletes and the restart-causing platform sign-in toggle ask through the dashboard's own confirmation dialog instead of the browser's.
    • Volumes entered when creating a service become managed volumes at their container path; the form dropped every volume before.

    Maintenance

    • @serve.zone/interfaces 32.15.0 → 32.36.0 and @api.global/typedsocket 8.4.0 → 8.7.0 (exact pins) in package.json, pnpm-lock.yaml and the binary's deno.lock, changing no other package's integrity and keeping the lock's registry origin. They are what Onebox needs to control Pallet locally: interfaces 32.36.0 carries the local controller contract (nodeRuntimeLocalControllerContract), local storage claims and the runtime log, stats, exec and volume archive contracts, and typedsocket 8.7.0 reaches a server over a Unix socket (unixSocketPath), which 8.4.0 cannot. No Onebox code changes with them.
    • The backup import specs are split over three files by concern (backup-import, backup-import-refusals, backup-import-space) with their two host doubles in test/helpers/backup-import.ts. Each double initializes its own encrypted archive, and Argon2id derives the passphrase key at every initialization (about 2–3 s on a loaded host), so the single file needed 56–76 s against its 60-second limit; each file now takes about 20 s.
    • mariadb 3.5.4 (LGPL-2.1-or-later) and @clickhouse/client 1.23.1 (Apache-2.0) are runtime dependencies now, the drivers @lossless.org/client/sqldb loads for MariaDB and ClickHouse, in package.json, pnpm-lock.yaml and the binary's deno.lock. The release binaries' THIRD_PARTY_NOTICES.md reproduces their license files, and those of denque and lru-cache, which mariadb brings, verbatim from Deno's npm cache at the versions the binary's deno.lock resolves (scripts/binary-notices.ts); mariadb's section states that it is LGPL-2.1-or-later, where its corresponding source is (its npm tarball, pinned by the release's lockfiles, and the upstream tag) and how to build Onebox with a modified copy. The release workflow checks the published notices for each of these texts (pnpm run check:binary-notices).
    • Release tooling: @git.zone/tsdeno ^1.12.0 → ^1.14.0 (with @git.zone/tsbundle 3.1.0 through it). The text of @epic-web/invariant, which ships no license file and reaches the binary through argon2, is named as a thirdPartyNotices supplement in .smartconfig.json, pointing at notices/third-party-notices.supplement.md. tsdeno's notices stay disabled until the libraries that embed license-less packages supply their texts; the release keeps assembling THIRD_PARTY_NOTICES.md with scripts/binary-notices.ts.
    • The WorkloadInit approval specs are split over four files by concern (workloadinit-approvals for the lifecycle, -restore, -deploy and -delete) with their shared fixture in test/helpers/workloadinit-approvals.ts. Every one of the 38 cases starts its own database and commits the approval steps as SmartDB transactions, each of which takes about 60–120 ms on this host (its journal is staged, renamed and fsynced file by file), so the single file needed about 50–58 s against its 60-second limit; each file now takes 13–20 s.
    • @design.estate/dees-catalog ^16.17.0 and @serve.zone/catalog ^34.1.0, one copy of each in the lockfile: status badges carry the status dot, and the catalog list views open a row with a single click. Removed dashboard code no route reached (the proxy view's DNS and domain branches, the services quick-deploy and backups sub-views, and an external-registries stub that only logged).
    • Release tooling currency: packageManager moves to pnpm@12.6.0 and @git.zone/tsbundle to ^3.1.0, the version the lockfile already resolved; @git.zone/tsbuild ^5.0.0, @git.zone/tsdeno ^1.14.0, @git.zone/tsrun ^3.0.2, @git.zone/tstest 6.3.2 and @git.zone/tswatch ^4.0.2 are already the current releases. pnpm and @types/node stop at the newest releases at least seven days old: pnpm 12.7.0 and @types/node 26.6.3 are younger, so @types/node stays at 26.6.2. No migration is due: the project has no folder tsconfig.json or tspublish.json (tsbuild 5), the dashboard bundle already writes the third-party notices tsbundle 3 requires, and no script reads process.argv through tsrun (tsrun 3). The release workflow takes pnpm from packageManager through corepack and asserts no pnpm version of its own; the lockfile keeps the npmjs sha512 integrity of every package.
    Downloads
  • v32.21.1 c7bf07e529
    Compare

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

    philkunz released this 2026-09-29 10:05:27 +00:00 | 71 commits to main since this release

    2026-09-29 - 32.21.1

    Fixes

    • Reach the Docker daemon again from the release binary. Onebox 32.21.0, the first release built with Deno 2.9.7, could not open the Docker socket: every Docker API request failed with invalid proxy url, so the daemon crash-looped at start with Failed to initialize Docker client: invalid proxy url. @push.rocks/smartrequest up to 5.5.0, which @apiclient.xyz/docker sends every request through, opened a Unix socket through the undocumented Deno.createHttpClient({ proxy: { url: 'unix://…' } }), which Deno 2.9.6 and later reject; 5.5.1 uses Deno's typed { transport: 'unix', path } proxy. @apiclient.xyz/docker moves from 9.2.0 to 10.1.1, which requires smartrequest ^5.5.1, in package.json, pnpm-lock.yaml and the binary's deno.lock, and both locks now resolve the single smartrequest 5.5.1 (from 5.0.4), keeping the sha512 integrity of every package and the lock's registry origin. Onebox reads no network IPAM or Labels, which 10.0.0 types as nullable, and never calls activateSwarm(), which rejects since 10.1.0, so no Onebox code changes with it; 9.3.0 addresses every absolute Unix socket path, /var/run/docker.sock included, as before.
    • The test suites and the binary check could not see this: Node takes smartrequest's Node transport, and the binary check ran only --version and the Typed RPC self-test, neither of which opens the Docker socket. The new onebox selftest docker reads the engine version through the Docker API client every Onebox Docker manager uses, from the daemon DOCKER_HOST names or else /var/run/docker.sock, and constructs nothing else. pnpm run verify:binary, which build:binary and the release workflow run, now starts a fake Docker API on a temporary Unix socket, runs the compiled x64 binary's selftest docker against it and requires the pass line and both the /_ping and /version requests to arrive; it fails with invalid proxy url on a binary built with smartrequest 5.0.4. Every binary run of the check is now bounded to 120 seconds.
    Downloads
  • v32.21.0 83e52efb16
    Compare

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

    philkunz released this 2026-09-29 06:55:18 +00:00 | 73 commits to main since this release

    Do not install v32.21.0. Its binaries cannot reach the Docker socket (invalid proxy url under Deno 2.9.6 and later) and crash-loop at start. Use v32.21.1, which fixes this.

    2026-09-29 - 32.21.0

    Features

    • Bundle the Cloudly App Store template 1.10.0 for Cloudly 33.7.0 through @serve.zone/appstore 32.10.0, moved from 32.9.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.10.0 on a host running template 1.2.1, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0 or 1.9.0 needs this release. The template pins the Cloudly 33.7.0 image index code.foss.global/serve.zone/cloudly@sha256:0b492a2511643981f003f1424715cf5abcdf39767fe5c995ad036a31b219f61e, keeps the 1.9.0 runtime contract (environment, both root-only secret files, platform OIDC, health check) and requires Onebox 32.4.0; against 1.9.0 only its image and changelog differ. Cloudly 33.7.0 lets a fresh greenfield service adopt a legacy service's Corestore database and bucket with their data through successorServiceId, refuses a deployment reservation whose release tag the service registry already holds a digest for with DEPLOYMENT_RELEASE_TAG_OCCUPIED, refuses an administrator's push to a reserved release tag, and pushes a platform binding's status back to its cluster relay only when it changed. It stores the adoption claims in a new collection and keeps the data version 0.23.0, so from 1.9.0 there is no data step. The template still marks the upgrade migration-required, backup-before-upgrade, breaking and manual-review, because hosts read these flags from the target version alone: from 1.8.0 and every earlier template Cloudly runs the forward-only data step deployment-machine-user-grants from 0.22.0 to 0.23.0 at its first start, from 1.6.0 and earlier the step runtime-session-protocol-offer from 0.21.0 to 0.22.0 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, and from 1.7.0 and earlier switch every username and password deployer to a machine-user token first. Let no deployment run while Cloudly upgrades. The template changelog carries forward the notes of the earlier templates, with the rollout order Cloudly 33.7.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.10.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, 1.8.0 and 1.9.0 (Cloudly 33.0.0, 33.1.0, 33.2.0, 33.3.0, 33.4.0, 33.5.0 and 33.6.0 images). App Store 32.10.0 still pins @serve.zone/interfaces 32.3.0, so no other runtime package moves.

    Maintenance

    • @design.estate/dees-catalog ^16.6.0 → ^16.12.0 in package.json and pnpm-lock.yaml, with @design.estate/dees-element 3.4.0 (from 3.3.0) through it; @serve.zone/catalog 33.0.0 (^16.4.0) resolves the same single copy of each, and the lockfile keeps the sha512 integrity of every package. No Onebox or @serve.zone/catalog view sets frameless or uses dees-stepper, dees-dashboardgrid or dees-input-list, so the transparent frameless surface of 16.12.0 and the removed stepper scroller/setScrollStatus() change no dashboard view.
    • Release tooling: the pinned Deno moves from 2.9.4 to 2.9.7, the release the other serve.zone binaries (Pallet, Spark, dcrouter) build with, in .smartconfig.json (denoVersion, which tsdeno compile enforces), the release workflow (the Deno toolchain and the seeded x64 and arm64 denort runtimes, each with the SHA-256 published with v2.9.7), binary/verify-runtime-cache.mjs and the readme. deno.lock stays as it is: Deno 2.9.7 checks every locked tarball origin against the configured registry, and Onebox's .npmrc names the same registry the lock records, so the frozen runtime graph warms and verifies unchanged (502 locked packages). The restore helper of test/corestore-backup.node.ts keeps its minimum of Deno 2.9.4, which is not the compile pin. The @git.zone/* build, test and release tools are already at their current releases; pnpm 12.6.0 and @types/node 26.6.3 still wait for the seven-day rule.
    • Release tooling: @git.zone/tsrun ^3.0.1 → ^3.0.2, which no longer loads two modules it never used, so every tsrun process starts about a second sooner.
    Downloads
  • 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 | 78 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