Confirmed. A stuck environment change from that failed second-volume attach is wedged in your production environment, and because changes apply one at a time, it's holding up the new iskcon-ebooks bucket from provisioning. We're clearing that stuck record on our side now.

Your live site, deployments, and existing volumes are all healthy and unaffected. Please hold off on making further environment changes in this project until we confirm it's cleared, so nothing else queues up behind it. We'll follow up here once the bucket can provision.

We found the cause. Your environment has a staged change set that is silently failing to apply: it's trying to attach a second volume to your iskcon_book_store service at /app/ebooks, but that service already has a volume mounted at /app/static/images/books. A service can only have one volume, so the change never applies and the pending banner never clears, which is also why the new volume can't provision.

We're clearing the stuck staged change for you now and will confirm once it's done. After that, you can attach the new volume to a service that doesn't already have one, or remove the existing volume first if you intend to replace it.

Done. We've cleared the stuck staged change on your production environment, so the pending banner should now be gone and the new volume/bucket can provision.

One thing to note for the retry: the change that was stuck tried to attach the new volume to your iskcon_book_store service, which already has a volume mounted at /app/static/images/books. A service can only have one volume, so please attach the new volume to a different service (one without an existing volume), or remove the current volume from iskcon_book_store first if you mean to replace it.

Give it a try and let us know if anything still looks off.

Thanks for clearing the stuck patch — confirmed on my end it's gone. However, the bucket still doesn't work: I created a brand new bucket from scratch (after your fix), and it still returns "BucketInstance not found" when I query its S3 credentials/instance details. So this looks like a separate issue from the stuck patch — buckets created via the public API don't seem to actually provision an instance. Could you check whether there's an additional provisioning step needed on your end for API-created buckets specifically? Bucket IDs to check: af555b06-5d51-451b-b8bd-32c5712664f8 (original) and e1af71e0-2b07-497e-9623-0f3247b9275f (fresh retry, same result). My live site and book images remain completely unaffected throughout.