@serve.zone/appstore 32.8.0 → 32.10.0

package/apps/cloudly/app.json

@@ -4,8 +4,8 @@
   "description": "Multi-node serve.zone control plane for clusters, workload services, domains, and deployments.",
   "category": "Dev Tools",
   "iconName": "server",
-  "latestVersion": "1.8.0",
-  "versions": ["1.0.0", "1.1.0", "1.1.1", "1.1.2", "1.1.3", "1.1.4", "1.1.5", "1.1.6", "1.1.7", "1.1.8", "1.1.9", "1.1.10", "1.2.0", "1.2.1", "1.3.0", "1.4.0", "1.5.0", "1.6.0", "1.7.0", "1.8.0"],
+  "latestVersion": "1.10.0",
+  "versions": ["1.0.0", "1.1.0", "1.1.1", "1.1.2", "1.1.3", "1.1.4", "1.1.5", "1.1.6", "1.1.7", "1.1.8", "1.1.9", "1.1.10", "1.2.0", "1.2.1", "1.3.0", "1.4.0", "1.5.0", "1.6.0", "1.7.0", "1.8.0", "1.9.0", "1.10.0"],
   "maintainer": "serve.zone",
   "links": {
     "Source": "https://code.foss.global/serve.zone/cloudly",

package/apps/cloudly/versions/1.10.0/config.json

@@ -0,0 +1,173 @@
+{
+  "image": "code.foss.global/serve.zone/cloudly@sha256:0b492a2511643981f003f1424715cf5abcdf39767fe5c995ad036a31b219f61e",
+  "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.7.0, a feature release over 33.6.0 that includes the fixes of 33.6.1. 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. The runtime contract is unchanged from 1.9.0 and requires Onebox 32.4.0. Cloudly 33.7.0 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. 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 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.7.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.7.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
+  }
+}

package/apps/cloudly/versions/1.9.0/config.json

@@ -0,0 +1,173 @@
+{
+  "image": "code.foss.global/serve.zone/cloudly@sha256:efcb200497b45ea14ef87155ac67a13a9be8eebd67801680122e84b9f3670c26",
+  "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.6.0, a feature and fix release over 33.5.0. 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. The runtime contract is unchanged from 1.8.0 and requires Onebox 32.4.0. From every earlier version, 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 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.6.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.6.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 every upgrade 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 the 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; hosts read these flags from the target version alone. 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
+  }
+}

package/appstore.json

@@ -151,7 +151,7 @@
       "description": "Multi-node serve.zone control plane for clusters, workload services, domains, and deployments.",
       "category": "Dev Tools",
       "iconName": "server",
-      "latestVersion": "1.8.0",
+      "latestVersion": "1.10.0",
       "tags": ["serve.zone", "control-plane", "clusters", "deployments"]
     },
     {

package/changelog.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## 2026-09-29 - 32.10.0
+
+### Features
+
+- publish the Cloudly 1.10.0 template for Cloudly 33.7.0 (cloudly)
+  - Add Cloudly app version 1.10.0, pinned to the Cloudly 33.7.0 multi-platform image index `code.foss.global/serve.zone/cloudly@sha256:0b492a2511643981f003f1424715cf5abcdf39767fe5c995ad036a31b219f61e` (linux/amd64 and linux/arm64), and mark it as the latest catalog version.
+  - Keep the 1.9.0 runtime contract and `minOneboxVersion` 32.4.0. Cloudly 33.6.1 and 33.7.0 change neither `qenv.yml` nor the Dockerfile and read no new environment variable, so every start-required variable is still a required template variable and `SERVEZONE_SSLMODE` stays `external`.
+  - Keep the upgrade breaking, manual-review, migration-required and backup-before-upgrade. Cloudly 33.7.0 adds no data step and keeps the data version 0.23.0, so an upgrade from 1.9.0 migrates nothing, but hosts read these flags from the target version alone and every upgrade from 1.8.0 or earlier still runs the forward-only step `deployment-machine-user-grants` on this image.
+  - The template changelog names the successor adoption of Cloudly 33.7.0 (`adoptCorestoreLegacyResources` with `successorServiceId`, interfaces 32.34.0, carried out by Corestore 33.2.0 or later, with its four new refusals) and the 33.6.1 fixes (`DEPLOYMENT_RELEASE_TAG_OCCUPIED` and the `VERSION_COLLISION` preflight for a registry-held release tag, `409 release-tag-reserved` for an administrator's push to a reserved tag, binding status pushed to the relay only on change). For installations on 1.8.0 or earlier it carries forward the 1.9.0 notes, with the rollout order Cloudly 33.7.0 before Coreflow 33.2.0.
+  - Update the bundled client data, the README guidance and the resolver regression coverage, which now holds 1.10.0 to the 1.9.0 runtime contract and upgrade flags.
+
+## 2026-09-28 - 32.9.0
+
+### Features
+
+- publish the Cloudly 1.9.0 template for Cloudly 33.6.0 (cloudly)
+  - Add Cloudly app version 1.9.0, pinned to the Cloudly 33.6.0 multi-platform image index `code.foss.global/serve.zone/cloudly@sha256:efcb200497b45ea14ef87155ac67a13a9be8eebd67801680122e84b9f3670c26` (linux/amd64 and linux/arm64), and mark it as the latest catalog version.
+  - Keep the 1.8.0 runtime contract and `minOneboxVersion` 32.4.0. Cloudly 33.6.0 changes neither `qenv.yml` nor the Dockerfile and reads no new environment variable, so every start-required variable is still a required template variable and `SERVEZONE_SSLMODE` stays `external`.
+  - Mark the upgrade migration-required and backup-before-upgrade, because Cloudly 33.6.0 moves the data version from 0.22.0 to 0.23.0 through the forward-only step `deployment-machine-user-grants`, which runs on every upgrade from an earlier template and permanently removes the deployment machine user grants no capability check reads (such as the `{ serviceId, capabilities }` grants of Cloudly 11); the way back is the pre-upgrade backup. Keep it breaking and manual-review, because the step removes stored data forward-only and hosts read these flags from the target version alone, so an installation on 1.7.0 or earlier also meets the deployment machine user reservation of Cloudly 33.5.0 on this image.
+  - The template changelog names the step, the graceful stop on SIGTERM and SIGINT (`Cloudly.stop()` within 8 seconds, below the 10-second stop grace of Docker and Swarm, exit 0 or 1; a second signal exits 143 or 130; SIGKILL still holds the database session until its timeout), which ends the `EFENCE_BUSY` crash loop after a stop, the per-service deployment namespace that lets two services of one project reserve without `DEPLOYMENT_RESOURCE_COLLISION`, and the `getDeploymentMachineUsers` fix for users configured under Cloudly 11. For installations on 1.7.0 or earlier it carries forward the 1.8.0 notes, with the rollout order Cloudly 33.6.0 before Coreflow 33.2.0.
+  - Update the bundled client data, the README guidance and the resolver regression coverage, which now holds 1.9.0 to the 1.8.0 runtime contract and upgrade flags.
+
 ## 2026-09-28 - 32.8.0
 
 ### Features