Deployment acceptance and recovery checks
After installation or upgrade, use test accounts and small samples. Record software versions, configuration, time and results.
| Check | Expected result |
|---|---|
| Administrator, user and enabled SSO login | Correct deployment, callback and roles |
| Upload and download a normal and LFS file | Matching content, type and owner |
| Authorized and unauthorized private repository access | Expected behavior through Web and Git/SDK |
| Deploy, call and stop a supported model | Correct response, useful logs and expected resource state |
| Valid and revoked gateway Keys | Authorized calls succeed; revoked Keys fail; usage can be reconciled |
| Metering and billing | EE meters without platform balance deductions; sites with billing enabled follow configured prices and owner |
| Runtime data | Pause preserves data; deletion removes instance data; exported copies remain readable |
| Offline operation | Required dependencies available internally; external services disabled or replaced as intended |
Before upgrading
Back up deployment configuration and versions, databases, repositories and LFS/object storage, important persistent volumes and required credentials through controlled procedures. A database backup alone does not restore all assets.
See Docker upgrade and Kubernetes upgrade/rollback. Quick installation can overwrite application configuration: save custom settings, domains, external service addresses and image versions first, then compare new configuration before restoring applicable settings.
Verify recovery
Restore configuration, databases and assets in an isolated test environment. Repeat login, permissions, download and model-call checks. Record the backup timestamp and recoverable data range before production changes. Do not overwrite new-version configuration blindly with old settings.