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

82 Releases 305 Tags

RSS Feed
  • 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 | 57 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