When a service activates, the module creates (on the storage server): the client's storage user (shared across their services), a per-service access key pair, the bucket (bucket-<clientID>-<serviceID>), the package quota, the visibility policy and the per-service IAM policy.
Important: when adding a service manually, add it as Pending and then Activate it — never directly as Active. The bucket name is derived from the service ID, which doesn't exist yet when a service is created directly as Active; the module blocks that attempt with a clear error.
Suspension is per-bucket: a deny-all policy is placed on that one bucket. The client's storage user is never disabled, so their other services keep working. Unsuspension restores the package's normal public/private policy.
Cancelling a service never deletes the bucket inline (a huge bucket can take hours to remove). Instead the bucket is queued in the Bucket Cleanup plugin and deleted through its staged, approval-gated flow — see the Bucket Cleanup Plugin article. If the cleanup plugin is not installed, cancellation is blocked.
If an admin reactivates a cancelled service, the cleanup plugin handles it automatically on its next hourly run:
Neither the cron nor the admin "Delete Now" button will ever delete a bucket whose service is active again.
On a service's admin page, the Advanced Features tab upgrades a legacy bucket (provisioned before module 2.3.0) so the client gets versioning/lifecycle self-service — it re-applies the current user policy and stamps the service. One click, POST-confirmed.