@serve.zone/appstore 32.14.0 → 32.15.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@serve.zone/appstore",
-  "version": "32.14.0",
+  "version": "32.15.0",
   "private": false,
   "description": "serve.zone App Store metadata, parser, and resolver client.",
   "type": "module",
@@ -11,11 +11,11 @@
   "license": "MIT",
   "dependencies": {
     "@push.rocks/smartversion": "^3.1.0",
-    "@serve.zone/interfaces": "32.3.0"
+    "@serve.zone/interfaces": "32.42.0"
   },
   "devDependencies": {
-    "@git.zone/tsbuild": "^5.0.0",
-    "@git.zone/tsdoc": "2.2.2",
+    "@git.zone/tsbuild": "^5.1.1",
+    "@git.zone/tsdoc": "3.0.1",
     "@git.zone/tstest": "6.3.2",
     "@types/node": "26.6.2"
   },

package/readme.md

@@ -33,7 +33,7 @@ The App Store currently lists 21 app templates.
 | App ID | Name | App Store category | Image | Port |
 | --- | --- | --- | --- | --- |
 | `adminer` | Adminer | Dev Tools | `adminer:latest` | `8080` |
-| `cloudly` | Cloudly | Dev Tools | `code.foss.global/serve.zone/cloudly@sha256:0925a1f053899655ec039a7751f51a640f7fc14e458a58d9f5a3e43f04ca9a9f` | `3000` |
+| `cloudly` | Cloudly | Dev Tools | `code.foss.global/serve.zone/cloudly@sha256:a49aa0a4f7b312656786f0d4b303cb40e25e766b98c778c83790948de43062be` | `3000` |
 | `ghost` | Ghost | CMS | `ghost:latest` | `2368` |
 | `gitea` | Gitea | Dev Tools | `gitea/gitea:latest` | `3000` |
 | `gitops` | GitOps | Dev Tools | `code.foss.global/serve.zone/gitops:2.13.0` | `3000` |
@@ -64,7 +64,7 @@ Some templates ask Onebox to provision local platform services and inject connec
 
 | App ID | Requirements | Notes |
 | --- | --- | --- |
-| `cloudly` | MongoDB, S3 | Version `1.14.0` pins Cloudly `33.8.3` and requires Onebox `32.4.0`. It keeps the `1.13.0` runtime contract and is marked breaking, migration-required, backup-before-upgrade and manual-review, because the flags are read from the target version alone and every upgrade from `1.8.0` or earlier migrates on this image; from `1.9.0`, `1.10.0`, `1.11.0`, `1.12.0` or `1.13.0` there is no data step, as the data version stays `0.23.0`. Cloudly `33.8.3` lets `deleteServiceById` retire a legacy service whose Corestore resources a successor adopted: its live Corestore bindings are tombstoned with the ordinary config push once every claimed legacy resource of each binding's capability has passed to the successor's live adopting binding, while a service without such a handover is still refused `CORESTORE_CLEANUP_TARGET_AUTHORITY_REQUIRED`. A legacy service whose runtime attestation a legacy-import operation still uses (`reserving`, `reserved`, `provisioning` or `awaiting-image`) is refused `SERVICE_LEGACY_IMPORT_PENDING` (retryable) and keeps running; import and deletion are serialized on the registry repository, so an import that starts after the check refuses as `LEGACY_IMPORT_SOURCE_MISMATCH`, and a deletion that proceeds deletes the attestations no release consumed. From `1.12.0` or earlier, Cloudly `33.8.2`'s fix applies too: Cloudly names why it refused a node's report: a refused `reportRuntimeNetworkProtection`, `reportRuntimeAssignmentTerminalReceipt`, `reportRuntimeAssignmentObservation` or `reportRuntimeAssignmentLogs` is logged as a warning once per node, report and distinct reason, and the node is answered with the unchanged error text plus `{ code: 'runtime-session-report-refused', reason }` as the error's data. From `1.11.0` or earlier, Cloudly `33.8.1`'s fix applies too: deploy before any Pallet that sends `discardedCaptures` or a `not-kept` log loss reaches a fleet node, since it accepts those log batch fields of interfaces `32.38.0`, which Cloudly `33.8.0` refuses on every retry, and still keeps no workload logs. From `1.10.0` or earlier, Cloudly `33.8.0`'s changes apply too: deploy before any Pallet that captures workload output reaches a fleet node, since Cloudly `33.8.0` answers a Pallet's `reportRuntimeAssignmentLogs` (interfaces `32.37.0`) with `not-kept`, which an earlier Cloudly leaves unhandled. Cloudly `33.8.0` lets a legacy `deployOnPush` service without deployable source move to a greenfield successor that runs the exact image it ran (`captureLegacyServiceRuntimeAttestation`, a `legacyImport` reservation under the capability `deployment:import-legacy`, and `importServiceDeploymentLegacyImage` in place of a push), judges promotion against the platforms of the service's rollout target, refuses a registry repository that belongs to another service as `REGISTRY_REPOSITORY_MISMATCH`, promotes and routes a service with a Corestore `database` or `objectstorage` binding again, and reads a node whose last report is older than 180 seconds as `offline`. Its web UI moved to path URLs and a regrouped menu, so bookmarks of the old UI locations open the not-found screen; server paths such as `/status` and the OIDC callback are unchanged. From `1.9.0` or earlier, Cloudly `33.7.0`'s changes apply: Cloudly `33.7.0` lets a fresh greenfield service take over a legacy service's Corestore database and bucket with their data and retention intact: an `adoptCorestoreLegacyResources` selection entry may name `successorServiceId` (interfaces `32.34.0`, carried out by Corestore `33.2.0` or later), the successor must share the owner's organization, be an immutable-deployment service, own no legacy resource of the capability and hold no other binding of it, and each legacy resource is adopted by one service only (`legacy-resource-adopted-elsewhere`, `successor-organization-mismatch`, `successor-not-greenfield`, `successor-owns-legacy-resource`). Since Cloudly `33.6.1`, a deployment reservation whose release tag the registry already holds is refused `DEPLOYMENT_RELEASE_TAG_OCCUPIED` instead of waiting for its image forever, an administrator's manifest push to a release tag a deployment operation reserved is refused `409 release-tag-reserved`, and a binding status report reaches its cluster relay only when it changed what the relay reads. From `1.8.0` or earlier, startup runs the forward-only data step `deployment-machine-user-grants` from `0.22.0` to `0.23.0`, 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 of Cloudly 11); stop Cloudly and take a verified backup first, as the way back is the pre-upgrade backup. Cloudly `33.6.0`'s changes apply too: Cloudly stops gracefully on SIGTERM and SIGINT within 8 seconds, below the 10-second stop grace of Docker and Swarm, so a stop or restart no longer leaves a database transaction held and the next start no longer crash-loops on `EFENCE_BUSY`; a process ended by SIGKILL still holds its database session until the server's session timeout. Every new service gets its own deployment namespace, so two services of one project reserve without `DEPLOYMENT_RESOURCE_COLLISION`, while a deployed service keeps its namespace, and `getDeploymentMachineUsers` lists users configured under Cloudly 11 again. From `1.7.0` or earlier, Cloudly `33.5.0`'s changes apply: Cloudly reserves a deployment only for a deployment machine user: `reserveServiceDeployment` refuses an administrator with `DEPLOYMENT_MACHINE_IDENTITY_REQUIRED`, including a deployer that signs in with a username and password (such as tsdeploy with `TSDEPLOY_CLOUDLY_USERNAME`/`TSDEPLOY_CLOUDLY_PASSWORD`), so before upgrading create a deployment machine user per deployer (`mutateDeploymentMachineUser`, or Security → Access → Deployment machine users in the dashboard), attach its grants with `configureServiceDeploymentMachineUser` and switch the deployer to its token; an existing `api` machine user with its grants already qualifies. A machine identity or registry bearer issued by an earlier release is refused until its holder exchanges its token again with `getIdentityByToken`, and removing a token now ends the sessions opened with it. Let no deployment run during the upgrade: a run in progress keeps its pre-upgrade identity and is refused for the rest of that run (rerun it, or resume it with `deploy-retry`). From `1.3.0` through `1.6.0`, startup runs the forward-only data step `runtime-session-protocol-offer` from `0.21.0` to `0.22.0`, which states `protocol: null` on every Pallet session row recorded before Cloudly stored its node's protocol offer; stop Cloudly and take a verified backup first, as rollback is full-restore-only. From `1.6.0`, Cloudly `33.4.0`'s changes apply: Cloudly `33.4.0` lets `setServicePublishedPorts` publish a contiguous range through `hostPortEnd` (at most 1024 ports in 64 entries per protocol) and same-port outbound through `symmetric: true`, which needs public egress (`published-port-symmetric-without-egress`) and owns its inside ports (`published-port-symmetric-inside-overlap`). New handoff leases translate outbound flows only into `49152-65535`, whose ports are refused `published-port-reserved`; a node keeps its `1024-65535` lease until its router is re-created. A policy write for a service being deleted is refused `service-deleting`. A projection carrying a range or a symmetric entry is withheld as `node-contract-behind` from a Pallet node whose session states a release below interfaces `32.31.0`, or an unrecorded one, so ranges and symmetric entries take effect on a node only once it runs a Pallet release built on interfaces `32.31.0` or later. From `1.5.0`, Cloudly `33.3.0`'s changes apply: Cloudly `33.3.0` lets an administrator set a service's network egress with `setServiceNetworkEgress` (public internet, and the platform endpoints of the protected authority), and refuses a workload whose database or object-storage binding sits on a node whose Corestore endpoint its network does not select as `database-endpoint-unselected` or `objectstorage-endpoint-unselected`; a replica already running keeps running while its target reports the refusal. From `1.4.0`, Cloudly `33.2.0`'s changes apply: Cloudly takes a dcrouter admin token once through `bootstrapExternalGatewayCredential` to provision its own gateway-client credential, starts a first enrollment with the gateway settings, and stages a gateway settings change the held credential cannot carry until the next bootstrap. From `1.2.1` or earlier, startup runs the forward-only migration from `0.20.0` to `0.21.0` before that step, dropping the relay certificate and DNS collections of Cloudly's retired Cloudflare and Let's Encrypt integration and logging every relay name whose A record Cloudly had written at Cloudflare, which the operator removes at the provider. dcrouter holds every cluster relay name's A record and certificate from then on, `SERVEZONE_SSLMODE=letsencrypt` is refused, and the typed API changes as the Cloudly 33.0.0 changelog lists. Stop Cloudly and take a verified backup before upgrading; rollback is full-restore-only. Roll out Cloudly `33.8.3` before Coreflow `33.2.0`; Coreflow `33.1.0` is the minimum. From `1.3.0`, also roll out Cloudly before Coreflow and Corestore `33.0.0`, and set every node's Corestore database endpoint, because a database binding on a node without one is not granted and its service is refused `database-endpoint-missing`, and existing database bindings return no credentials until they are granted again for the endpoint. From `1.1.10` or earlier, startup first runs the `1.2.0` steps from `0.10.0` and needs completed Secrets v2 cutover retirement. Both the existing Secrets v2 keyring and operator-approved WorkloadInit authority are required encrypted inputs delivered as separate root-owned `0400` files; the public environment contains only their fixed paths. |
+| `cloudly` | MongoDB, S3 | Version `1.15.0` pins Cloudly `33.10.0` and requires Onebox `32.4.0`. It keeps the `1.14.0` runtime contract and is marked breaking, migration-required, backup-before-upgrade and manual-review, because the flags are read from the target version alone and every upgrade from `1.8.0` or earlier migrates on this image; from `1.9.0`, `1.10.0`, `1.11.0`, `1.12.0`, `1.13.0` or `1.14.0` there is no data step, as the data version stays `0.23.0`. Cloudly `33.10.0` lets an operator obtain a cluster relay's bearer without an exec into Cloudly's process: `exportClusterRelayAuthorization` (interfaces `32.41.0`) requires a freshly signed-in administrator, proves the delivered credential version against the hash its generation issued, commits an audit receipt fenced at that generation before it answers the bearer, and never logs it; the receipts live in the new collection `cloudly_cluster_relay_authorization_exports`, installed at startup and listed by `getClusterRelayAuthorizationExports`, and `servezone relay export-authorization` (`@serve.zone/cli` `33.10.0`) writes the bearer as a new `0600` file. From `1.14.0` or earlier, Cloudly `33.9.0`'s changes apply too: a node's managed VPN member is kept across its network projection changes instead of being withdrawn from the hub network on every workload change (`bindGetRuntimeManagedVpnCredentialSuccessor`, interfaces `32.39.0`), the failure cause a node reports with a failed run (interfaces `32.40.0`) is stored and shown in the runtime assignment views and the dashboard's Cause column, and `deleteServiceById` answers success once a service is marked for deletion while another deleting service drains, naming its refusals `SERVICE_LIFECYCLE_BUSY`, `SERVICE_ORGANIZATION_AUTHORITY_REQUIRED` and `SERVICE_MANAGER_STOPPING` instead of an internal error. From `1.13.0` or earlier, Cloudly `33.8.3`'s fix applies too: it lets `deleteServiceById` retire a legacy service whose Corestore resources a successor adopted: its live Corestore bindings are tombstoned with the ordinary config push once every claimed legacy resource of each binding's capability has passed to the successor's live adopting binding, while a service without such a handover is still refused `CORESTORE_CLEANUP_TARGET_AUTHORITY_REQUIRED`. A legacy service whose runtime attestation a legacy-import operation still uses (`reserving`, `reserved`, `provisioning` or `awaiting-image`) is refused `SERVICE_LEGACY_IMPORT_PENDING` (retryable) and keeps running; import and deletion are serialized on the registry repository, so an import that starts after the check refuses as `LEGACY_IMPORT_SOURCE_MISMATCH`, and a deletion that proceeds deletes the attestations no release consumed. From `1.12.0` or earlier, Cloudly `33.8.2`'s fix applies too: Cloudly names why it refused a node's report: a refused `reportRuntimeNetworkProtection`, `reportRuntimeAssignmentTerminalReceipt`, `reportRuntimeAssignmentObservation` or `reportRuntimeAssignmentLogs` is logged as a warning once per node, report and distinct reason, and the node is answered with the unchanged error text plus `{ code: 'runtime-session-report-refused', reason }` as the error's data. From `1.11.0` or earlier, Cloudly `33.8.1`'s fix applies too: deploy before any Pallet that sends `discardedCaptures` or a `not-kept` log loss reaches a fleet node, since it accepts those log batch fields of interfaces `32.38.0`, which Cloudly `33.8.0` refuses on every retry, and still keeps no workload logs. From `1.10.0` or earlier, Cloudly `33.8.0`'s changes apply too: deploy before any Pallet that captures workload output reaches a fleet node, since Cloudly `33.8.0` answers a Pallet's `reportRuntimeAssignmentLogs` (interfaces `32.37.0`) with `not-kept`, which an earlier Cloudly leaves unhandled. Cloudly `33.8.0` lets a legacy `deployOnPush` service without deployable source move to a greenfield successor that runs the exact image it ran (`captureLegacyServiceRuntimeAttestation`, a `legacyImport` reservation under the capability `deployment:import-legacy`, and `importServiceDeploymentLegacyImage` in place of a push), judges promotion against the platforms of the service's rollout target, refuses a registry repository that belongs to another service as `REGISTRY_REPOSITORY_MISMATCH`, promotes and routes a service with a Corestore `database` or `objectstorage` binding again, and reads a node whose last report is older than 180 seconds as `offline`. Its web UI moved to path URLs and a regrouped menu, so bookmarks of the old UI locations open the not-found screen; server paths such as `/status` and the OIDC callback are unchanged. From `1.9.0` or earlier, Cloudly `33.7.0`'s changes apply: Cloudly `33.7.0` lets a fresh greenfield service take over a legacy service's Corestore database and bucket with their data and retention intact: an `adoptCorestoreLegacyResources` selection entry may name `successorServiceId` (interfaces `32.34.0`, carried out by Corestore `33.2.0` or later), the successor must share the owner's organization, be an immutable-deployment service, own no legacy resource of the capability and hold no other binding of it, and each legacy resource is adopted by one service only (`legacy-resource-adopted-elsewhere`, `successor-organization-mismatch`, `successor-not-greenfield`, `successor-owns-legacy-resource`). Since Cloudly `33.6.1`, a deployment reservation whose release tag the registry already holds is refused `DEPLOYMENT_RELEASE_TAG_OCCUPIED` instead of waiting for its image forever, an administrator's manifest push to a release tag a deployment operation reserved is refused `409 release-tag-reserved`, and a binding status report reaches its cluster relay only when it changed what the relay reads. From `1.8.0` or earlier, startup runs the forward-only data step `deployment-machine-user-grants` from `0.22.0` to `0.23.0`, 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 of Cloudly 11); stop Cloudly and take a verified backup first, as the way back is the pre-upgrade backup. Cloudly `33.6.0`'s changes apply too: Cloudly stops gracefully on SIGTERM and SIGINT within 8 seconds, below the 10-second stop grace of Docker and Swarm, so a stop or restart no longer leaves a database transaction held and the next start no longer crash-loops on `EFENCE_BUSY`; a process ended by SIGKILL still holds its database session until the server's session timeout. Every new service gets its own deployment namespace, so two services of one project reserve without `DEPLOYMENT_RESOURCE_COLLISION`, while a deployed service keeps its namespace, and `getDeploymentMachineUsers` lists users configured under Cloudly 11 again. From `1.7.0` or earlier, Cloudly `33.5.0`'s changes apply: Cloudly reserves a deployment only for a deployment machine user: `reserveServiceDeployment` refuses an administrator with `DEPLOYMENT_MACHINE_IDENTITY_REQUIRED`, including a deployer that signs in with a username and password (such as tsdeploy with `TSDEPLOY_CLOUDLY_USERNAME`/`TSDEPLOY_CLOUDLY_PASSWORD`), so before upgrading create a deployment machine user per deployer (`mutateDeploymentMachineUser`, or Security → Access → Deployment machine users in the dashboard), attach its grants with `configureServiceDeploymentMachineUser` and switch the deployer to its token; an existing `api` machine user with its grants already qualifies. A machine identity or registry bearer issued by an earlier release is refused until its holder exchanges its token again with `getIdentityByToken`, and removing a token now ends the sessions opened with it. Let no deployment run during the upgrade: a run in progress keeps its pre-upgrade identity and is refused for the rest of that run (rerun it, or resume it with `deploy-retry`). From `1.3.0` through `1.6.0`, startup runs the forward-only data step `runtime-session-protocol-offer` from `0.21.0` to `0.22.0`, which states `protocol: null` on every Pallet session row recorded before Cloudly stored its node's protocol offer; stop Cloudly and take a verified backup first, as rollback is full-restore-only. From `1.6.0`, Cloudly `33.4.0`'s changes apply: Cloudly `33.4.0` lets `setServicePublishedPorts` publish a contiguous range through `hostPortEnd` (at most 1024 ports in 64 entries per protocol) and same-port outbound through `symmetric: true`, which needs public egress (`published-port-symmetric-without-egress`) and owns its inside ports (`published-port-symmetric-inside-overlap`). New handoff leases translate outbound flows only into `49152-65535`, whose ports are refused `published-port-reserved`; a node keeps its `1024-65535` lease until its router is re-created. A policy write for a service being deleted is refused `service-deleting`. A projection carrying a range or a symmetric entry is withheld as `node-contract-behind` from a Pallet node whose session states a release below interfaces `32.31.0`, or an unrecorded one, so ranges and symmetric entries take effect on a node only once it runs a Pallet release built on interfaces `32.31.0` or later. From `1.5.0`, Cloudly `33.3.0`'s changes apply: Cloudly `33.3.0` lets an administrator set a service's network egress with `setServiceNetworkEgress` (public internet, and the platform endpoints of the protected authority), and refuses a workload whose database or object-storage binding sits on a node whose Corestore endpoint its network does not select as `database-endpoint-unselected` or `objectstorage-endpoint-unselected`; a replica already running keeps running while its target reports the refusal. From `1.4.0`, Cloudly `33.2.0`'s changes apply: Cloudly takes a dcrouter admin token once through `bootstrapExternalGatewayCredential` to provision its own gateway-client credential, starts a first enrollment with the gateway settings, and stages a gateway settings change the held credential cannot carry until the next bootstrap. From `1.2.1` or earlier, startup runs the forward-only migration from `0.20.0` to `0.21.0` before that step, dropping the relay certificate and DNS collections of Cloudly's retired Cloudflare and Let's Encrypt integration and logging every relay name whose A record Cloudly had written at Cloudflare, which the operator removes at the provider. dcrouter holds every cluster relay name's A record and certificate from then on, `SERVEZONE_SSLMODE=letsencrypt` is refused, and the typed API changes as the Cloudly 33.0.0 changelog lists. Stop Cloudly and take a verified backup before upgrading; rollback is full-restore-only. Roll out Cloudly `33.10.0` before Coreflow `33.2.0`; Coreflow `33.1.0` is the minimum. From `1.3.0`, also roll out Cloudly before Coreflow and Corestore `33.0.0`, and set every node's Corestore database endpoint, because a database binding on a node without one is not granted and its service is refused `database-endpoint-missing`, and existing database bindings return no credentials until they are granted again for the endpoint. From `1.1.10` or earlier, startup first runs the `1.2.0` steps from `0.10.0` and needs completed Secrets v2 cutover retirement. Both the existing Secrets v2 keyring and operator-approved WorkloadInit authority are required encrypted inputs delivered as separate root-owned `0400` files; the public environment contains only their fixed paths. |
 | `ghost` | MariaDB | Uses MySQL-style `database__connection__*` environment variables. |
 | `gitea` | MariaDB | Uses Gitea database environment variables with `${MARIADB_*}` placeholders. |
 | `nextcloud` | MariaDB, Valkey | Uses MySQL-compatible database variables. Valkey is declared as a platform requirement. |

package/ts_client/data.generated.ts

@@ -34,7 +34,7 @@ export const appStorePackageData: IAppStorePackageData = {
       "description": "Multi-node serve.zone control plane for clusters, workload services, domains, and deployments.",
       "category": "Dev Tools",
       "iconName": "server",
-      "latestVersion": "1.14.0",
+      "latestVersion": "1.15.0",
       "versions": [
         "1.0.0",
         "1.1.0",
@@ -61,7 +61,8 @@ export const appStorePackageData: IAppStorePackageData = {
         "1.11.0",
         "1.12.0",
         "1.13.0",
-        "1.14.0"
+        "1.14.0",
+        "1.15.0"
       ],
       "maintainer": "serve.zone",
       "links": {
@@ -2695,6 +2696,179 @@ export const appStorePackageData: IAppStorePackageData = {
         "expectedStatus": 200
       }
     },
+    "apps/cloudly/versions/1.15.0/config.json": {
+      "image": "code.foss.global/serve.zone/cloudly@sha256:a49aa0a4f7b312656786f0d4b303cb40e25e766b98c778c83790948de43062be",
+      "targetPorts": [
+        {
+          "name": "web",
+          "port": 3000,
+          "protocol": "http",
+          "default": true
+        }
+      ],
+      "envVars": [
+        {
+          "key": "SERVEZONE_ENVIRONMENT",
+          "value": "production",
+          "description": "Cloudly runtime environment.",
+          "required": true
+        },
+        {
+          "key": "SERVEZONE_PUBLIC_ORIGIN",
+          "value": "https://${SERVICE_DOMAIN}",
+          "description": "Canonical public Cloudly origin including protocol and optional public port.",
+          "required": true
+        },
+        {
+          "key": "SERVEZONE_LISTENPORT",
+          "value": "3000",
+          "description": "Internal Cloudly HTTP port inside the container.",
+          "required": true
+        },
+        {
+          "key": "SERVEZONE_SSLMODE",
+          "value": "external",
+          "description": "Use external TLS termination through Onebox or dcrouter.",
+          "required": true
+        },
+        {
+          "key": "SERVEZONE_SECRET_KEYRING_PATH",
+          "value": "/run/secrets/cloudly-secrets-v2-keyring.json",
+          "description": "Path to the Cloudly Secrets v2 keyring mounted by Onebox; the keyring value is never placed in the public environment.",
+          "required": true
+        },
+        {
+          "key": "SERVEZONE_SECRET_KEYRING_FILE",
+          "description": "Existing Cloudly Secrets v2 keyring. Onebox stores it encrypted and mounts it only as a root-readable file; retain the existing keyring when upgrading.",
+          "required": true,
+          "secret": true,
+          "delivery": {
+            "type": "file",
+            "targetPath": "/run/secrets/cloudly-secrets-v2-keyring.json",
+            "uid": 0,
+            "gid": 0,
+            "mode": 256
+          }
+        },
+        {
+          "key": "SERVEZONE_WORKLOADINIT_APPROVAL_PATH",
+          "value": "/run/secrets/cloudly-workloadinit-approval.json",
+          "description": "Private WorkloadInit release-approval artifact mounted by Onebox for Coreflow secret-runtime registration.",
+          "required": true
+        },
+        {
+          "key": "SERVEZONE_WORKLOADINIT_APPROVAL_FILE",
+          "description": "Operator-approved WorkloadInit release authority. Onebox stores it encrypted and mounts it only as a root-readable file.",
+          "required": true,
+          "secret": true,
+          "delivery": {
+            "type": "file",
+            "targetPath": "/run/secrets/cloudly-workloadinit-approval.json",
+            "uid": 0,
+            "gid": 0,
+            "mode": 256
+          }
+        },
+        {
+          "key": "MONGODB_URL",
+          "value": "${MONGODB_URI}",
+          "description": "Authenticated MongoDB wire-protocol URL provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "MONGODB_NAME",
+          "value": "${MONGODB_DATABASE}",
+          "description": "MongoDB wire-protocol database name provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "MONGODB_USER",
+          "value": "${MONGODB_USERNAME}",
+          "description": "MongoDB wire-protocol username provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "MONGODB_PASS",
+          "value": "${MONGODB_PASSWORD}",
+          "description": "MongoDB wire-protocol password provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "S3_ENDPOINT",
+          "value": "onebox-corestore",
+          "description": "S3 endpoint host provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "S3_PORT",
+          "value": "9000",
+          "description": "S3 endpoint port provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "S3_USESSL",
+          "value": "false",
+          "description": "Use plain HTTP for internal Corestore S3 traffic on the Onebox network.",
+          "required": true
+        },
+        {
+          "key": "S3_BUCKET",
+          "value": "${S3_BUCKET}",
+          "description": "S3 bucket provisioned by Onebox Corestore for Cloudly's registry.",
+          "required": true
+        },
+        {
+          "key": "S3_ACCESSKEY",
+          "value": "${S3_ACCESS_KEY}",
+          "description": "S3 access key provisioned by Onebox Corestore.",
+          "required": true
+        },
+        {
+          "key": "S3_SECRETKEY",
+          "value": "${S3_SECRET_KEY}",
+          "description": "S3 secret key provisioned by Onebox Corestore.",
+          "required": true
+        }
+      ],
+      "platformRequirements": {
+        "mongodb": true,
+        "s3": true
+      },
+      "platformOidc": {
+        "redirectPath": "/auth/oidc/callback",
+        "roles": [
+          {
+            "id": "admin",
+            "label": "Administrator",
+            "description": "Full Cloudly administration for this hosted instance."
+          },
+          {
+            "id": "user",
+            "label": "User",
+            "description": "Standard authenticated Cloudly access for this hosted instance."
+          }
+        ],
+        "environmentVariables": {
+          "issuerUrl": "SERVEZONE_PLATFORM_OIDC_ISSUER",
+          "clientId": "SERVEZONE_PLATFORM_OIDC_CLIENT_ID",
+          "clientSecret": "SERVEZONE_PLATFORM_OIDC_CLIENT_SECRET",
+          "redirectUri": "SERVEZONE_PLATFORM_OIDC_REDIRECT_URI",
+          "audience": "SERVEZONE_PLATFORM_OIDC_AUDIENCE"
+        },
+        "clientAuthenticationMethod": "client_secret_basic"
+      },
+      "minOneboxVersion": "32.4.0",
+      "changelog": "Move Cloudly to 33.10.0, which lets an operator obtain a cluster relay's bearer without an exec into Cloudly's process. The new administrator request exportClusterRelayAuthorization (interfaces 32.41.0) requires a freshly signed-in administrator, reads the version the relay credential delivered at exactly the requested generation and proves it against the hash that generation issued, then writes an audit receipt in a transaction that fences the administrator and the credential at that generation, and answers the bearer only after the receipt commits. Its refusals are the contract's clusterRelayAuthorizationExportRefusals, every other failure is one denial text, and nothing on the path logs the bearer. The receipts live in the new collection cloudly_cluster_relay_authorization_exports, which Cloudly installs at startup like every other collection, are listed by getClusterRelayAuthorizationExports and are removed with a deleted cluster's other relay authority records. The servezone relay export-authorization command of @serve.zone/cli 33.10.0 fetches the bearer through @serve.zone/api 32.4.0 and writes it as a new 0600 file, exclusive and atomic, and prints only its size, SHA-256 and receipt id. From 1.14.0 or earlier, the changes of Cloudly 33.9.0 apply too: a node's managed VPN member is kept across its network projection changes. Every workload add, removal, readiness, egress or policy change signs a new projection, and until now each one withdrew the node from its cluster's hub network, dropped its hub session and cut every workload on it off the network. Cloudly now moves the member onto a successor projection of the same membership (the same projection lineage, protected authority and handoff) under the key pair it holds, through bindGetRuntimeManagedVpnCredentialSuccessor (interfaces 32.39.0), and a credential request naming the successor gets the same key pair; membership still ends on a registration, a protection bump, a lost session, a relay that re-keys its hub, another membership or a lapsed DNS window. Cloudly stores the failure cause a node reports with a failed observation (interfaces 32.40.0: an image pull's refusal reason and gRPC status, an exit code, runtime-absent or network-epoch-ended), getServiceRuntimeAssignments and the cluster page carry it and the dashboard's runtime tab shows it in a Cause column, while every failed run is still replaced on the same backoff, whatever its cause. deleteServiceById answers success once a service is marked for deletion, even while another deleting service waits for its runtime to drain: a deleting service now protects nothing in the registry, which ends the internal error Protected OCI manifest is missing on every later deletion, and the deletion's own refusals SERVICE_LIFECYCLE_BUSY, SERVICE_ORGANIZATION_AUTHORITY_REQUIRED and SERVICE_MANAGER_STOPPING are answered by name instead of Internal server error. The runtime contract is unchanged from 1.14.0 and requires Onebox 32.4.0. Cloudly 33.10.0 keeps the data version 0.23.0, so from 1.9.0, 1.10.0, 1.11.0, 1.12.0, 1.13.0 or 1.14.0 there is no data step. From 1.13.0 or earlier, the fix of Cloudly 33.8.3 applies too, which lets deleteServiceById retire a legacy service whose Corestore resources a successor adopted. A service with a Corestore binding but no immutable deployment plan was always refused CORESTORE_CLEANUP_TARGET_AUTHORITY_REQUIRED, so a legacy owner whose database or bucket had passed to its successor could never be deleted. Its live Corestore bindings are now tombstoned with the ordinary config push once every claimed legacy resource of each binding's capability has passed to a successor: the CorestoreLegacyAdoptionClaim must name the successor's live adopting binding, and that binding's node must list the resource as authorized for exactly that binding or no longer list it for the owner. The successor's binding and the resource it adopted are never touched, and a service without such a handover is still refused. A legacy service is kept while a successor still imports its image: its deletion is refused SERVICE_LEGACY_IMPORT_PENDING (retryable) while a legacy-import operation of one of its runtime attestations is reserving, reserved, provisioning or awaiting-image, checked before the service is marked deleting and again inside the registry's mutation serialization that deletes its repository. A legacy import reads its source under that same serialization, so an import that starts after the check refuses as LEGACY_IMPORT_SOURCE_MISMATCH instead of copying from a repository being deleted. A deletion that proceeds deletes the attestations no release consumed and keeps those a release's cloudly-legacy-import evidence names. From 1.12.0 or earlier, the fix of Cloudly 33.8.2 applies too, which names why a node's report was refused, in Cloudly's log and to the node: a refused reportRuntimeNetworkProtection, reportRuntimeAssignmentTerminalReceipt, reportRuntimeAssignmentObservation or reportRuntimeAssignmentLogs is logged as a warning with the node, the reason and a bounded cause chain, once per node, report and distinct reason until that report is accepted again, and the node is answered with the same fixed text plus { code: 'runtime-session-report-refused', reason } as the error's data. Every check of a network protection receipt names itself, such as reporter-session-unknown, request-binding-rejected, protected-authority-unknown, receipt-replay-conflict or receipt-admission-rejected; other refusals are named by their code, and a failure that is not a refusal is unclassified. The wire text is unchanged, so an older Pallet reads the refusal as before. From 1.11.0 or earlier, the fix of Cloudly 33.8.1 applies too, so deploy this release before any Pallet that sends discardedCaptures or a not-kept log loss reaches a fleet node: reportRuntimeAssignmentLogs now accepts the log batch fields of interfaces 32.38.0, the optional node-level count discardedCaptures and the loss reason not-kept, while Cloudly 33.8.0 read a batch by the exact 32.37.0 schema and refused either one on every retry, so a node that discarded captures under a not-kept answer would retry that batch forever. Cloudly still keeps no workload logs: it answers not-kept for exactly that batch, records nothing and leaves the count with the node for a later controller that keeps logs. From 1.10.0 or earlier, the changes of Cloudly 33.8.0 apply too, so deploy this release before any Pallet that captures workload output reaches a fleet node: Cloudly now answers a Pallet's reportRuntimeAssignmentLogs (interfaces 32.37.0), keeps no workload logs yet and answers every batch arriving on the node's current session not-kept for exactly that batch, so the node sends no more batches on that session, while a batch on another connection, a replaced session or plain HTTP, or one the contract rejects, is refused; an earlier Cloudly leaves the method unhandled, so such a Pallet cannot tell it from a failure worth retrying. A legacy deployOnPush service without deployable source can move to a greenfield successor that runs the exact image it ran (interfaces 32.36.0): while the legacy replicas still run, an administrator captures captureLegacyServiceRuntimeAttestation, which requires every required replica healthy on one digest and stores that digest, the registry root its tag names and the root's runnable Linux platform manifests once per legacy service and root (getLegacyServiceRuntimeAttestations lists them), and refuses incomplete evidence without storing anything. A greenfield reservation and its preflight may name that attestation as legacyImport in place of a source revision; they require the capability deployment:import-legacy and report LEGACY_IMPORT_ATTESTATION_MISSING, LEGACY_IMPORT_SOURCE_MISMATCH or LEGACY_IMPORT_PLATFORM_MISMATCH. Instead of a registry push the deployer calls importServiceDeploymentLegacyImage, and Cloudly copies the attested image from its own registry into the reserved tag, keeping the digest of the platform manifest the legacy runtime ran, and records release evidence of source cloudly-legacy-import; nothing may push to a legacy-import operation, and retiring the legacy service afterwards leaves the imported release whole. Promotion and the promote-phase preflight require exactly the platforms of the service's rollout target instead of a runnable linux/amd64 and linux/arm64 index of every release, so a single-platform release promotes onto a spec-owned target of that platform; adoption of a Coreflow deployment still requires both. A deployment reservation and its reserve-phase preflight refuse a registry repository that already belongs to another service as REGISTRY_REPOSITORY_MISMATCH, naming that service, so a successor sharing its legacy service's name and id prefix no longer derives the legacy repository. A deployment whose service uses a Corestore database or objectstorage binding can be promoted and routed again, because the ready binding is now the evidence instead of an entry in Corestore's resource inventory; a held greenfield service's first promote preflight accepts its binding while it waits for the grant that promotion releases and reports PLATFORM_BINDING_READINESS_DEFERRED, and the route preflight still requires the binding ready. A node whose last report is older than 180 seconds reads offline instead of online and ready in getNodes, getNodeById, the node UI and the MCP node summary, while its stored record is unchanged and its next accepted report reads online again; getRuntimeNetworkNodeReadiness states node-observation-stale with lastObservedAt, a run is admitted only on a node observed running, and an immutable rollout on a Coreflow cluster whose only or pinned node went stale is refused with no online target nodes. The web UI runs in a new shell with path URLs and a regrouped menu, so bookmarks of the old UI locations, such as /runtime/services, open the not-found screen; the server's own paths, among them /status, the OIDC callback and the registry, stay where they were, and deletes, kills, reboots and revokes ask through a confirmation dialog. Cloudly 33.8.0 stores the legacy runtime attestations in a new collection and adds no data step. From 1.9.0 or earlier, the changes of Cloudly 33.7.0 and the fixes of 33.6.1 apply too: a fresh greenfield service can take over a legacy service's Corestore database and bucket with their data and retention intact: an adoptCorestoreLegacyResources selection entry may name successorServiceId (interfaces 32.34.0), and the adopting binding is then created on that successor with corestoreLegacyAdoption.legacyServiceId naming the legacy owner, and the plan entry carries the successor for Corestore's offline adoption, which Corestore 33.2.0 is the first release to read. The successor must share the owner's organization, be an immutable-deployment service, own no legacy resource of the capability and hold no other binding of it, and a legacy resource is adopted by one service only, enforced by a claim written in the adoption's transaction; the new refusals are legacy-resource-adopted-elsewhere, successor-organization-mismatch, successor-not-greenfield and successor-owns-legacy-resource, and each created adoption is logged. Until now a legacy service replaced by a greenfield deployment stranded its data, since only its own binding could adopt it. A deployment reservation whose release tag the service registry already holds a digest for is refused DEPLOYMENT_RELEASE_TAG_OCCUPIED, not retryable, whoever pushed it, instead of being left awaiting its image forever, and the reserve-phase preflight reports such a tag as VERSION_COLLISION unless the operation's own push bound that digest, for existing services and greenfield deployments alike. An administrator's manifest push to a release tag a deployment operation reserved is refused 409 release-tag-reserved, naming the operation, and a claim read that fails refuses the push; unreserved release tags and mutable tags keep the administrator's write access. A platform binding's status report is pushed back to its cluster relay only when it changed what the relay reads (status, reason, endpoints, bucket name or Corestore authority fence), which ends the loop of about one push a second with a relay that kept reporting the same failed state; every report is still recorded in the service's reconciliation status, and a change whose push failed after it was stored is pushed again with the binding's next report. From 1.8.0 or earlier, the changes of Cloudly 33.6.0 apply too: every new service gets its own deployment namespace, <name>-<id digest>-v<major> with twelve hex digits of the SHA-256 of the service id, so two services of one project on one Cloudly both reserve instead of the second being refused DEPLOYMENT_RESOURCE_COLLISION; a service already holding its project-only namespace keeps it, as does an operation reserved under it, so no deployed service moves and no data changes. Cloudly now stops gracefully on SIGTERM and SIGINT: the first signal runs Cloudly.stop(), which closes the database last, and the process exits 0 when the stop completes and 1 when it fails or has not completed within 8 seconds, below the 10-second stop grace of Docker and Swarm, so stopping or restarting the Cloudly service no longer leaves a database transaction held on the server and the next start no longer crash-loops on EFENCE_BUSY until the server's 30-minute session timeout; a second signal exits at once with 143 (SIGTERM) or 130 (SIGINT), and a process ended by SIGKILL still holds its database session until that timeout. getDeploymentMachineUsers lists a deployment machine user configured under Cloudly 11 again instead of failing the whole listing with an unnamed internal error, a stored user the listing still cannot describe fails it with an error naming the user and the refused part (identity, tokens or grants), and every unexpected failure of getDeploymentMachineUsers or mutateDeploymentMachineUser is logged with each error of its chain. From 1.8.0 or earlier, startup runs the forward-only data migration from 0.22.0 to 0.23.0 through the step deployment-machine-user-grants, which keeps on every deployment machine user exactly the grants a capability check reads, the first valid grant per organization and service, and permanently removes the rest, such as the { serviceId, capabilities } grants stored by Cloudly 11; tokens, names and every deployment's authority stay as they are. Stop Cloudly and take a verified backup before upgrading, because the step has no inverse and rollback requires a full restore. From 1.7.0 or earlier, the deployment machine users of Cloudly 33.5.0 apply too: a deployment is reserved only by a deployment machine user. reserveServiceDeployment refuses any other verified actor, an administrator included, with DEPLOYMENT_MACHINE_IDENTITY_REQUIRED before anything is reserved, and the reserve-phase getDeploymentPreflight reports the same blocker; an existing api machine user with its grants already qualifies and needs no change. A deployer that signs in with a username and password, such as tsdeploy with TSDEPLOY_CLOUDLY_USERNAME and TSDEPLOY_CLOUDLY_PASSWORD, is an administrator and is refused, so switch it to a machine-user token before upgrading from 1.7.0 or earlier: create a deployment machine user per deployer with mutateDeploymentMachineUser or Security → Access → Deployment machine users in the dashboard, attach its grants with configureServiceDeploymentMachineUser, and give its username and token to the deployer. An operation an administrator reserved earlier stays awaiting its image; clean it up with cleanupServiceDeployment. mutateDeploymentMachineUser creates an API machine user with one token (create), replaces every token of one with a new token (rotate-token) or removes its tokens while its grants stay (revoke-token); the token is answered once and expires at most a year after the mutation, and getDeploymentMachineUsers lists every deployment machine user with its token expiries and grants and never a token value. The identity getIdentityByToken issues and the registry bearer of a machine login now name the SHA-256 of their token, and every verification checks that the user still holds that unexpired token, so removing a token ends the sessions opened with it. A machine identity or registry bearer issued by an earlier release names no token and is refused, so its holder exchanges its token again: a deployer such as tsdeploy does so on every run, while a long-running API or administrator machine client that keeps its identity across a reconnect calls getIdentityByToken once more after the upgrade; cluster identities, including relays on the shared cluster token, and service workload identities are unaffected. Let no deployment run while Cloudly upgrades: a run in progress keeps its pre-upgrade identity and is refused for the rest of that run, so rerun it or resume it with deploy-retry. The cluster config broadcast now reaches the elected relay of every cluster, so a Corestore endpoint written on a node of a Pallet cluster, and every other broadcast, reaches that cluster's relay at once instead of when it reconnects, and setServiceRuntimeSpec refuses a spec the runtime spec contract rejects as Service runtime operation rejected: invalid. instead of Internal server error, and stores nothing. From 1.6.0, startup first runs the forward-only data migration from 0.21.0 to 0.22.0 through the step runtime-session-protocol-offer, which states protocol: null on every Pallet session row recorded before Cloudly stored the protocol offer its node stated, so such a node counts as unrecorded until it registers again; that step has no inverse either. The published-port ranges of Cloudly 33.4.0 apply too: setServicePublishedPorts publishes a contiguous range through hostPortEnd and same-port outbound through symmetric: true, which needs public egress (published-port-symmetric-without-egress) and owns its inside ports (published-port-symmetric-inside-overlap); new handoff leases translate outbound flows only into the SNAT band 49152-65535, whose ports are refused published-port-reserved, while a node keeps its 1024-65535 lease until its router is re-created; a service network policy write for a service whose deletion has begun is refused service-deleting; and a projection carrying a range or a symmetric entry is withheld as node-contract-behind from a Pallet node whose session states a release below interfaces 32.31.0, or none. From 1.5.0 the same step runs, and the service network egress of Cloudly 33.3.0 applies too: an administrator sets a service's network egress with setServiceNetworkEgress, which states whether the service's attached workloads reach the public internet and which platform endpoints of the protected authority they reach, and reads it with getServiceNetworkEgress; a workload whose enabled database or object-storage binding sits on a node whose Corestore endpoint its network does not select is refused database-endpoint-unselected or objectstorage-endpoint-unselected, and a replica already running keeps running while its target reports the refusal, so grant the endpoint through the service's egress before such a workload is placed again; the default runtime spec of a new service probes its process instead of its first TCP target port. From 1.4.0 the same step runs, and the gateway admin bootstrap of Cloudly 33.2.0 applies too: an administrator hands Cloudly a dcrouter admin token once through bootstrapExternalGatewayCredential or servezone gateway bootstrap, from which Cloudly provisions and stores its own gateway-client credential; a first enrollment turns admin-bootstrap-required, a gateway settings change the held credential cannot carry is staged, a runtime network address plan out of its canonical order is refused plan-unsorted, and a relay naming a node Cloudly does not hold is refused relay-node-unknown: roll out Cloudly 33.10.0 first, then Coreflow 33.2.0, which recognises the relay-node-unknown refusal. From 1.3.0 the same step runs, and the per-node database endpoint of Cloudly 33.1.0 applies too: roll out Cloudly 33.10.0 first, then Coreflow 33.2.0 (33.1.0 at minimum), then Corestore 33.0.0, and set every node's Corestore database endpoint with setClusterNodeCorestoreDatabaseEndpoint, because a database binding on a node without one is not granted and its service is refused database-endpoint-missing, and existing database bindings answer no credential material until they are granted again for the endpoint. From 1.2.1 or earlier, startup runs the forward-only data migration from 0.20.0 to 0.21.0 through the step retire-cluster-relay-acme and then the steps runtime-session-protocol-offer to 0.22.0 and deployment-machine-user-grants to 0.23.0; retire-cluster-relay-acme drops the relay certificate and DNS collections of Cloudly's retired Cloudflare and Let's Encrypt integration and logs every relay name whose A record Cloudly had written at Cloudflare: remove each such record at the provider. A cluster relay then requires a dcrouter that advertises dns.clientRecords and certificates.exactIssuance, SERVEZONE_SSLMODE=letsencrypt is refused (this template keeps external), and the typed API changes as the Breaking Changes of the Cloudly 33.0.0 changelog list; review them, stop Cloudly and take a verified backup before upgrading, because the 32.9 image refuses the migrated data and rollback requires a full restore. The upgrade is marked migration-required and backup-before-upgrade because hosts read these flags from the target version alone and every upgrade from 1.8.0 or earlier runs the 0.22.0 to 0.23.0 step, an upgrade from 1.6.0 or earlier runs the 0.21.0 to 0.22.0 step before it and one from 1.2.1 or earlier the migration from 0.20.0 as well, and breaking and manual-review because that step removes stored grants forward-only and, from 1.7.0 or earlier, a username and password deployer, an administrator's deployment reservation and a machine identity or registry bearer issued earlier are refused. An installation on 1.1.10 or earlier also runs the 1.2.0 steps first, from 0.10.0, and requires completed Secrets v2 cutover retirement. Preserve existing user and storage identities, OIDC bindings, the encrypted keyring and WorkloadInit approval as dedicated root-readable files.",
+      "breaking": true,
+      "requiresManualReview": true,
+      "migrationRequired": true,
+      "backupBeforeUpgrade": true,
+      "healthCheck": {
+        "path": "/status",
+        "port": 3000,
+        "expectedStatus": 200
+      }
+    },
     "apps/cloudly/versions/1.2.0/config.json": {
       "image": "code.foss.global/serve.zone/cloudly@sha256:9731dcf7d56567235017008994a00b2a4eeb7fd64a7d801bee0933fd6eede007",
       "targetPorts": [
@@ -5280,7 +5454,7 @@ export const appStorePackageData: IAppStorePackageData = {
           "description": "Multi-node serve.zone control plane for clusters, workload services, domains, and deployments.",
           "category": "Dev Tools",
           "iconName": "server",
-          "latestVersion": "1.14.0",
+          "latestVersion": "1.15.0",
           "tags": [
             "serve.zone",
             "control-plane",