@serve.zone/appstore 32.27.0 → 33.0.0

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

@@ -1,173 +0,0 @@
-{
-  "image": "code.foss.global/serve.zone/cloudly@sha256:f0da8c0ef826d2e044aa49ec1b59533f7be16c372357dbf818fe488ccdc5b0c9",
-  "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 32.9.1, a fixes-only patch over 32.9.0: a certificate request for a relay-namespace name whose relay is not enabled is refused, a route whose certificate Cloudly cannot obtain or whose hostname or service conflicts is left out of its cluster's ingress route table instead of freezing or withdrawing the whole table, and service admission refuses relay-namespace hostnames and hostnames another service's deployment route claim owns. 32.9.1 adds no data migration step and keeps the 1.2.0 runtime contract, so upgrading from 1.2.0 needs no manual review, data migration or backup. An installation on 1.1.10 or earlier still runs the 1.2.0 startup migration to 0.20.0 on this image: it requires completed Secrets v2 cutover retirement and a fresh verified restorable checkpoint, and rolling it back requires a full restore. Requires Onebox 32.4.0. Preserve existing user and storage identities, OIDC bindings, the encrypted keyring and WorkloadInit approval as dedicated root-readable files.",
-  "breaking": false,
-  "requiresManualReview": false,
-  "migrationRequired": false,
-  "backupBeforeUpgrade": false,
-  "healthCheck": {
-    "path": "/status",
-    "port": 3000,
-    "expectedStatus": 200
-  }
-}

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

@@ -1,173 +0,0 @@
-{
-  "image": "code.foss.global/serve.zone/cloudly@sha256:7156b37a0ecba08e6a9803fd8bfd10da2b4f6970257077f7af8a57d947398a76",
-  "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": "Cloudly's own S3 bucket, provisioned by Onebox Corestore: registry storage and kept workload logs.",
-      "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": "33.8.0",
-  "changelog": "Move Cloudly to 33.15.0. Cloudly keeps workload logs: it answered every reportRuntimeAssignmentLogs batch not-kept, so the node discarded it and a failed run's output was lost. Each attempt now gets its log record in the transaction that issues it, holding its run revision and its config's log policy, so its batches bind after the slot released the assignment record too; a batch Cloudly holds already, by its capture's high-water mark, is answered replay, and a new batch's payload is written first to runtime-logs/<serviceId>/<assignmentId>/<captureId>/<sequence>.json in Cloudly's own bucket, the S3 bucket this template already binds as S3_BUCKET, and only then is its ledger row committed. A batch of an attempt Cloudly never issued or whose logs it let go is refused log-attempt-unkept, and a new number after a capture's final batch log-capture-ended. Kept logs are bounded per attempt to 8 MiB of line text and 8192 batches and per slot to the newest 8 attempts, and each batch lives for its config's logs.retentionMs; the oldest batches go first and the capture's truncation states them (batch-cap, byte-cap or retention), never a silent drop. One sweep drops expired batches and attempts and removes objects no row names once they are an hour old. Operators read kept logs with getServiceRuntimeLogAttempts and getRuntimeAssignmentLogs (interfaces 32.47.0), authorized like getServiceRuntimeAssignments, and the service page's Logs tab shows the newest attempt. A Pallet-executed rollout that succeeded stays succeeded: after a node reboot its replica's expected network-epoch-ended failure turned the rollout failed for good while its replacement ran healthy and verified; a later replica failure, crash or replacement is now the service's runtime health, read from the live runtime tasks of a deployment status, a fresh digest mismatch still fails the rollout, a Pallet rollout that failed before it succeeded stays failed, and a Coreflow-reported rollout keeps its 33.14.2 rules. A failing service runtime pass names its step (ServiceRuntimeProductionError with plan, build, approval, commit, verdict, view, rollout or announce), the plain errors it and the network producer could raise carry closed codes, and a database error is named by its code name and number, such as MongoServerError [WriteConflict 112], never by its message. A launcher secret written before a service's first image plan, such as a cluster ingress bearer, left the service refused secrets-unsupported after its promotion; every writer of an image plan (a promotion, an automatic release, an adoption and an adoption rollout) now publishes the service's secret deployment plan in the same transaction, and a promotion, automatic release or adoption whose secrets cannot be published fails (SECRET_CONFIGURATION_REVISION_CONFLICT or SECRET_OWNER_INVALID) instead of leaving the service refused at runtime. The designated cluster ingress runs with SERVEZONE_CLUSTER_RELAY_ORIGIN and SERVEZONE_CLUSTER_NODE_ID beside its bearer, so CoreTraffic in cluster-ingress mode no longer exits with QenvMissingRequiredEnvVars: a cluster that states no valid relay refuses its ingress cluster-relay-missing (an administrator enables the relay with enableClusterRelay), an ingress service whose own environment sets one of the three names is refused cluster-ingress-environment-conflict, and a relay origin that moves replaces the ingress replicas. Cloudly writes both into the ingress workload's environment, not its own, so this template sets neither. Cloudly 33.15.0 changes neither qenv.yml nor the Dockerfile, and the runtime contract is that of 1.19.0 except that it requires Onebox 33.8.0 or later (platform Corestore 32.2.4, NoSQLDB 10.6.1 with the D3 fix): on an earlier engine the first transaction to commit wins, so a node's network plan, which holds the controller fence for its whole pass while reports and the other producers keep committing short transactions on it, lost every commit to a WriteConflict until its 120-second transaction budget ran out, and Cloudly 33.15.0 must not run on such an engine. The S3_BUCKET description now names both uses of Cloudly's own bucket, registry storage and kept workload logs. The first start runs the forward-only data migration from 0.24.0 to 0.25.0 through the step runtime-log-attempts, which writes the log record of every slot's current attempt issued before this release, with the time the step ran as its issuedAt, so the batches its node delivers are kept; a database without slots is left untouched and a rerun writes nothing. The step has no inverse and every earlier Cloudly refuses the 0.25.0 data (DOWNGRADE_NOT_SUPPORTED), so stop Cloudly and take a verified backup before upgrading: rollback requires a full restore of that backup. From 1.18.0 or earlier, the changes of Cloudly 33.14.1 and 33.14.2 apply too: a rollout Pallet executes now completes: Cloudly read a service's image rollout only from Coreflow reports, so every rollout on a Pallet-attached cluster stayed pending with no reporters and its deployment operation stayed rolling-out although its runs were ready, and tsdeploy timed out on every Pallet-attached service. Cloudly now reports on every rollout whose target clusters are all on Pallet, one reporter per target cluster (pallet/<clusterId>) over the runs of exactly the current desire, verified when the digest the node observed and the digest the run was sealed to are both the requested one: the rollout moves through verifying to succeeded (or ready-for-route), fails when a run fails, and a run of an earlier generation never vouches for the next one. getServiceDeploymentStatus reads such a rollout's runtime tasks from the runtime manager instead of Coreflow, Coreflow and Pallet rollouts succeed, fail and honour the startup grace by the same rules, and a rollout that also targets a cluster not yet on Pallet is still read from Coreflow. A launcher-secret run admitted after a Cloudly restart gets its material again: Cloudly treated a node's secret recipient as active only on the exact session that enrolled it, so after any Cloudly restart, reconnect or credential rotation every new or replacement secret-bearing run waited secret-mount-uncertain (secret-recipient-inactive) until the node process was restarted; the recipient is now active for every session the enrolling node process registers, and for no session of a restarted node, which enrolls a new generation. A failing producer pass is logged: each failing candidate of the runtime network and service runtime producers is logged under its producer's subject once per change of cause, with how long the attempt ran (runtime network projection of node <id> failed after <ms> ms: <cause>, service runtime of service <id> failed after …), and its recovery once (… produced again: <outcome>); a failed listing is logged as the sweep's, a failed sweep the timer started is no longer dropped, and the node network, node retirement, service retirement, protection and relay passes report theirs the same way. The cause names error classes, codes and checks only, never a value: the network producer names the failing step (plan, membership or compile) and the compiler names its check, such as network-projection-rejected or network-endpoint-limit. Nothing persisted changes shape: the secret recipient still records the session that enrolled it, and a Pallet rollout's verdict is written to the same imageRolloutStatus that Coreflow reports write. Cloudly 33.14.0 through 33.14.2 keep the data version 0.24.0, so from 1.16.0 the 0.24.0 to 0.25.0 step is the only data step. From 1.17.0 or earlier, the changes of Cloudly 33.14.0 apply too: a platform-owned service's published ports take infrastructure-administrator authority, while every organization service keeps the federated organization-owner rule: an administrator designates a service of a platform organization (an organization id carrying ':', such as legacy:Service:<id>, as a cluster ingress or a platform call router has no idp.global organization) with designatePlatformOwnedService, withdraws it with undesignatePlatformOwnedService and reads it with getServicePlatformOwnership (interfaces 32.45.0), and from then on getServicePublishedPorts and setServicePublishedPorts for that service require a verified administrator and no organization owner. Any other organization id, an idp.global nanoid included, is refused organization-not-platform before the service is read; the other refusals are service-unknown, service-deleting and conflict, and a caller without the authority the service requires is answered one denial text. Withdrawing a designation leaves the service's published ports with no writer until it is designated again. Both published-port requests read the designation inside one admitted operation, a designation counts only while it names the service's current organization, and a designation change committed before the write's transaction refuses the write as conflict. The designation is stored on the service document, so it adds no collection and no data step. Every assignment dispatch is named: Cloudly records each push's outcome under a closed, value-free reason (accepted, replay, historical, acknowledged, node-busy, node-not-connected, session-moved, intent-not-current, request-unbound, node-refused, push-failed or acknowledgement-unbound), logs it when it changes for that assignment, naming only the error classes and codes of a failure, and pushes a refused or unanswered push again on the next pass under the same session. A run its node refused before any runtime effect (the failure cause refused of interfaces 32.45.0) is no longer replaced on the failure backoff but kept until its spec or another input of the assignment changes, a refused container (container-refused) is still replaced like any other failure, and the dashboard's runtime tab names both causes. From 1.16.0 or earlier, the changes of Cloudly 33.13.3 and 33.13.4 apply too: a run whose secret reaches its process through the WorkloadInit launcher gets its material again: Cloudly compared the run's pinned artifact with the approved one as JSON strings, which never matched the canonical form the admitted authority holds, so every launcher-delivered run's material, Corestore's MONGODB_URI included, was denied after several seconds; the artifact is now compared member by member, by its platform and both digests. Every reader of the WorkloadInit approval asks one loader, which reads the file and judges its revocation and timeline on every call but remembers a successful verification of an active artifact by the artifact's SHA-256 and never a failed one, so a material request no longer waits for a registry verification each time. A refused material request names its check: the node is answered with the fixed text and { code: 'runtime-session-report-refused', reason }, where reason is a closed, value-free word such as workloadinit-approval-unavailable, secret-manifest-not-accepted or secret-retention-absent, and Cloudly logs it once per change of reason for a node and request, naming only error classes, codes and the reason. Since Cloudly 33.13.3 a node's session is pushed each assignment revision once: the delivery pass replays every desired assignment every 5 seconds by default and pushed each one again whether the node had acknowledged it or not, so every node repeated a full admission per assignment every few seconds; a new revision, a new session and a restarted Cloudly push again. From 1.15.0 or earlier, the changes of Cloudly 33.11.0 through 33.13.2 apply too: the first start runs the forward-only data migration from 0.23.0 to 0.24.0 through the step corestore-control-token-state, which records a Corestore control token stored before Cloudly 33.11.0 as revision 1, without a receipt. The step has no inverse and every earlier Cloudly refuses the migrated data (DOWNGRADE_NOT_SUPPORTED), so stop Cloudly and take a verified backup before upgrading: rollback requires a full restore of that backup. An administrator sets the Corestore control token without an exec into Cloudly's container: setCorestoreControlToken (interfaces 32.42.0) requires a freshly signed-in administrator and stores the token under both Corestore provider configs in one transaction that fences the administrator, compares the stored state with the request's exact expected state, advances the revision by one and writes a value-free receipt, and getCorestoreControlTokenState answers the state and the latest 4096 receipts. Its refusals are the contract's corestoreControlTokenSetRefusals, every other failure is one denial text, and the token is never answered, recorded or logged. The revision lives in the new collection cloudly_corestore_control_token_state and the receipts in cloudly_corestore_control_token_receipts, which Cloudly installs at startup like every other collection. The in-container secrets set-corestore-control-token --stdin stores through the same transaction and answers the state and receipt it stored, and servezone corestore set-control-token --stdin --expect absent|<revision> and servezone corestore control-token-state of @serve.zone/cli set and read the token through @serve.zone/api 32.5.0. A protected-authority step that only adds, such as a node joining the egress or a cluster hub joining the platform endpoints, now keeps every managed VPN member instead of withdrawing every node of the fleet from its cluster's hub network and re-keying it; the first authority, a moved hub or a changed pool still withdraws them all. retireClusterNode (interfaces 32.43.0) retires a node out of the Pallet runtime and its egress owner out of the protected authority: a node the authority does not name and a lost node are admitted at once, a withdrawn egress owner is queued and admitted in a group of at most sixteen, and only an admitted node leaves every producer's scope, is refused registration and walks the egress fence until both its credentials are revoked. An admitted owner whose session speaks interfaces 32.44.0 or later is asked through its projection to withdraw its allocation protection, so a cleanly stopped, crashed, rebooting or offline node on interfaces 32.44.0 no longer blocks allocation for the whole fleet. A stopping workload's lease stays in its node's network projection as a never-ready endpoint until the node's stop receipt is accepted, so stopping an attached workload no longer makes the node refuse its in-place transition and withdraw its tunnel. From 1.14.0 or earlier, the changes of Cloudly 33.10.0 apply too, which let 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. From 1.9.0 through 1.15.0, the 0.23.0 to 0.24.0 and 0.24.0 to 0.25.0 steps are the only data steps. 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.15.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.15.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, deployment-machine-user-grants to 0.23.0, corestore-control-token-state to 0.24.0 and runtime-log-attempts to 0.25.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.19.0 or earlier runs the 0.24.0 to 0.25.0 step, an upgrade from 1.15.0 or earlier runs the 0.23.0 to 0.24.0 step before it, one from 1.8.0 or earlier the 0.22.0 to 0.23.0 step before that, one from 1.6.0 or earlier the 0.21.0 to 0.22.0 step before that and one from 1.2.1 or earlier the migration from 0.20.0 as well, and breaking and manual-review because every earlier Cloudly refuses the 0.25.0 data, the 0.23.0 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
-  }
-}