There are two different ownership changes here. Uninstall removes Premium's customer services according to a reviewed plan. Ejection exports an accepted application deployment as standalone infrastructure source so you can take over its management.
#Understand: removal and export
| Operation | What it does | What it does not imply |
|---|---|---|
| Premium uninstall | Removes the planned companion services and reports retained resources | Delete all application data or cancel your subscription |
| Core ejection | Writes a reviewed standalone Pulumi project preserving resource identities | Delete, recreate, or stop the live application |
| Remove an extension grant | Changes an application's declared capability access | Uninstall customer services |
An export contains source, not the credentials or state needed to operate it. A retained cloud resource can still incur costs after uninstall. Read the result as an ownership report, not simply a success message.
#Configure: review the intended ownership change
Use the exact workspace, current installation credentials, and stable passphrase from your secret store. Identify dependent applications and inspect the accepted deployment before proceeding.
#Preview Premium uninstall
fluffy-chainsaw-premium uninstall --checkReview the resources selected for removal, their ordering, and the retained data/recovery evidence. Check mode does not remove infrastructure, but the planning operation may persist its plan records in customer state.
#Apply Premium uninstall
After reviewing that plan:
fluffy-chainsaw-premium uninstallConfirm the deployment name when prompted. Noninteractive use requires --yes. After completion, verify that removed services are unavailable and that retained application/data resources match the report. Review retained resources separately if you intend to remove them later.
Control Room is one of the services governed by the removal plan. It has no remote ejection button. Account/subscription changes remain in Platform. If application code uses the Premium extension, update its code and grants, regenerate, and review its deployment as a separate change.
#Export an accepted Core deployment
For an application already deployed successfully, select a new workspace-relative directory and a credential-free backend URL under your control:
fluffy-chainsaw deploy eject \
--application example-app --environment prod \
--output infrastructure/example-app-prod \
--backend gs://your-pulumi-state \
--checkReview the reported source and digest. Repeat the same command without --check and with --approve sha256:REVIEW_DIGEST, substituting the exact digest it reported. The output directory must be absent or empty.
Ejection rechecks the accepted plan and authoritative checkpoint. It refuses partial, pending, foreign, or changed state. The emitted project preserves resource identities, pinned dependencies, and retention policy; it excludes state, credentials, and the passphrase.
Read the emitted handover instructions before taking over deployment ownership, particularly when moving the state backend. The export itself does not move live state or uninstall the application.
#Reference: verify the handover
| Check | Why it matters |
|---|---|
| Target application/environment | Avoid exporting a different accepted deployment |
| Resource identities | A replacement identity can mean replacement infrastructure |
| Retention policy | Understand which resources persist through later changes |
| Pinned dependencies | Keep the exported implementation reproducible |
| State/backend handover instructions | Source alone is not enough to adopt existing resources |
| Retained-resource report after uninstall | Remaining resources still need an owner and cost review |
A changed checkpoint requires a fresh review and approval digest. Do not reuse a digest from an earlier plan. Credential or identity errors require the correct installation session and ADC. Missing retained resources should be investigated against the plan; generating another export does not recreate them.
CLI reference lists the accepted flags. Database recovery covers data restoration, which is separate from both workflows.