What it doesBasics
- Prepare draft releases and upload approved platform artifacts
- Publish, promote, demote, withdraw and retire releases
- Retrieve exact artifacts with integrity and signature verification
- Inspect signing keys, request rotation and maintain the CLI
First useBasics
- Obtain the approved Linux amd64 or arm64 executable and verify its published digest through your distribution process.
- Run
uaas versionanduaas help; select the approved environment and credential. - Run
uaas product listanduaas channel list --product-id PRODUCT_IDfor the approved scope. - Read the full result; perform mutations only under the owner’s approved plan.
- Restore temporary settings afterward. A read-only trial needs no record deletion.
Everyday tasksEveryday use
Inspect the approved release scope
A publisher needs to confirm catalog identity before a write.
- Confirm deployment and required product permission.
- Run
uaas product list, thenuaas channel list --product-id PRODUCT_ID. - Read the known release with
uaas release show --product-id PRODUCT_ID RELEASE_ID; use list for its channel.
What you getThe exact product, release and intended channel are established.
How to check: Release list is capped at 200 records and some details are omitted. Absence from a list is not proof of absence.
Prepare and publish an approved build
A release owner has approved a version and platform support matrix.
- Create a draft with
uaas release create --product-id PRODUCT_ID --version VERSION --channel edge --update-type upgrade; use full instead only when intended. - Upload each approved artifact with
uaas release upload --product-id PRODUCT_ID --release-id VERSION --platform PLATFORM --file ARTIFACT. - Read back the draft and compare all platforms with the approved matrix.
- Publish with
uaas release publish --product-id PRODUCT_ID VERSION. - Download the exact version to a dedicated path, then follow the release owner’s installation and ordinary functional acceptance procedure.
What you getThe approved bytes are available and a real consumer operation has been verified.
How to check: Upload alone is not publication; publication alone is not installation. First publication has no previous platform set for comparison. An approved platform drop requires both --allow-platform-drop and --reason.
Expand a verified rollout
An accepted release is ready for the next more-stable channel.
- Record its exact ID, current channel and active status.
- Run
uaas release promote --product-id PRODUCT_ID --version VERSIONonce after approval. - Inspect the matching list row for the new channel and active state; use the service owner’s supported view if outside the list window.
- Verify required pruning separately and confirm the intended consumer offer.
What you getThe release reaches the approved channel with understood cleanup.
How to check: Promotion can succeed while pruning fails. Repeating an ambiguous promotion can advance another channel; demotion does not roll back installed machines.
Recover an interrupted artifact transfer
A large upload or exact download failed partway through.
- Keep the approved source file unchanged and inspect current release state.
- An upload at or above 100 MiB uses chunking; retry with the same file and target only after reconciliation.
- For download, confirm exact active version, platform and channel visibility and use a dedicated destination.
- Require completed size, checksum and signature verification before executing the downloaded artifact.
What you getThe intended artifact is transferred and independently accepted.
How to check: A finalized upload can still have a lost response. Old destination files and temporary download files are not success evidence; unchanged published bytes may be accepted as a no-op.
Retire content or rotate signing keys
The service owner approved a distribution or signing change.
- Record release state, accepted replacement and retention decision before withdrawal, archive or deletion.
- Run only the approved transition, then inspect the exact record and consumer behavior.
- For key rotation, record
uaas key list, runuaas key rotateonce, then verify the new active ID and prior trusted ID. - Verify an approved new signature and retained old artifact with their intended consumers.
What you getThe intended catalog or key state is established and the recovery plan remains usable.
How to check: Rotation is service-wide and does not revoke old trust. Withdrawal cannot recall downloaded bytes; product deletion affects its entire catalog scope. Inspect before retrying a lost response.
Settings to decideAdvanced
- Confirm the assigned environment
- MAIT_CHANNEL selects stable, beta or edge for release builds; saved installation selection can otherwise apply. Correct configuration warnings before a write: fallback can select stable. Deployment selection and release-channel entitlement are separate.
- Choose the intended credential
- UAAS_CREDENTIALS_PATH takes precedence even when empty; a nonempty CREDENTIALS_PATH otherwise applies before user/system discovery. Unset an unwanted override. Optional settings use ~/.mait/uaas.yaml or /etc/mait/uaas.yaml; there is no arbitrary service-URL flag.
- Restore the session deliberately
- Record non-secret settings before changes. Restore temporary overrides afterward; do not remove shared credentials, grants or cache directories as routine read-only cleanup.
- Account for request and notification timing
- Administrative requests allow 600 seconds each; a transfer can span several requests and retries. UAAS_UPDATE_COOLDOWN defaults to 600 seconds. UAAS_UPDATE_TIMEOUT does not change this CLI’s request deadline, and re-execution/grace settings do not enable installation of staged updates.
CommandsAdvanced
Problems and fixesHelp
Good to knowHelp
- Sign-in does not grant every administrative permission. Inspect the full result and resulting state.
- Uploading, publishing and successful customer installation are separate results.
- Updates are staged; this CLI does not install them on the next launch.