Storage

With yesterday's outage of Spaces of over 4 hours, why is there no SLA for Spaces availability? This was a costly outage but customers have no recourse. There's no mention of Spaces SLA here: https://docs.digitalocean.com/platform/slas/ . Can DigitalOcean consider adding one to protect against future incidents? Consider competitor SLAs: Amazon S3: https://aws.amazon.com/s3/sla/ Backblaze B2: https://www.backblaze.com/company/policy/sla

Please prioritise having individual keys for individual spaces. It's pretty useless with multiple products or clients. I can't use it for backup for instance, because every other project will be able to access these backups if compromised.

It will be nice to have built-in feature to download DigitalOcean Spaces files as zip within the Spaces filemanager.

Spaces needs access logs.. so we can know what's happening under the hood It's the only reason I use AWS CloudFront instead.. here's their access log: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html

I'm setting up an application where I need to upload and download images, I need to store the large original images and occasionally serve the full images via a direct download link, but more often I need to provide a small mobile/reduced sized version of that image. I'm looking to use https://imgproxy.net/ to do so, however I would like to also be able to still use the CDN to cache the images that come out of this resizing so I can serve the most commonly used, smaller images at the edge. The goal is to proxy requests from client -> cdn -> imgproxy -> spaces so I always only serve the size I need, and I can cache it at the edge. Currently from what I can see in the documentation, there is no way to place any processing between the CDN and Spaces, and I've had this confirmed by support.

Currently, we are using the STS method to upload from the frontend on AWS S3. However, DigitalOcean Spaces does not support STS. Therefore, we cannot migrate to DigitalOcean Spaces. Using the STS method, we can directly upload from the frontend. In this way, users can upload more efficiently without tiring the backend.

We looked into using Digital Ocean but there was no way to validate if user uploaded images were safe. On Google Cloud we can automatically block porn, violence and other dodgy images/video automatically using AI. Because of this DO is not a viable platform for us to use.

Stand-alone CDN (not coupled with Spaces) would be very useful.

This seems like a bug or missing feature (I know it can be workarounded using DigitalOcean API or doctl compute cdn flush $cdn_id --files $file ). The issue is when doing any file changes in DigitalOcean Spaces e.g. uploading an updated file using s3cmd - it is still stuck in CDN with the old file. Why DigitalOcean doesn't automatically purge file from CDN when the file is identified as changed or even removed? For example if https://cdn.mydomain.com/test.jpg doesn't exist, after I upload test.jpg to space https://cdn.mydomain.com/test.jpg would display it without requiring me to purge CDN cache. It is not consistent with case if test.jpg already exist and after I delete it or upload modified test.jpg, now https://cdn.mydomain.com/test.jpg still be stuck with the old file. DigitalOcean should automatically identify change and purge it from CDN cache.