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.

Good news first: confirmed the stuck patch is fully cleared and your production environment is healthy, deployments and volumes all READY.

On the new issue, you diagnosed it correctly. This is not a leftover of the stuck patch. Creating a bucket through the public API (bucketCreate) only creates the bucket record itself. It does not currently provision the actual storage instance or its S3 credentials, which is why both af555b06 and e1af71e0 return "BucketInstance not found". The environment deployment part of the API mutation is not wired up yet, so an API-only bucket never gets an instance.

The reliable path today is to create the bucket from the dashboard (project canvas, New > Bucket) and deploy/commit the change. That route stages and applies the bucket instance, provisions it into your production environment, and generates the S3 credentials. Once it shows up there, querying credentials will return a real endpoint and keys.

You can delete the two empty API-created buckets to avoid confusion. I've flagged the API provisioning gap internally so the mutation gets fixed. Your live site and book images were never at risk here.

Let me know once you've created one from the dashboard and I'll confirm the instance provisioned on our side.

— Angelo