Storage

Problem - DigitalOcean currently provides: * Auto-Scaling Droplet Pools * Load Balancers * Managed Databases * Block Storage Volumes However, Droplet storage is locally attached and cannot be shared across droplets. This prevents customers from building true high-availability, horizontally scalable environments for platforms such as: * CyberPanel / cPanel hosting * WordPress / WooCommerce * Shared hosting platforms * Any file-dependent PHP or web workload Even with Load Balancers, users face: * Filesystem inconsistency * Plugin / theme sync problems * Upload duplication * Session issues * Expensive & fragile DIY storage workarounds So today, non-Kubernetes customers cannot scale web workloads reliably. --- Requested Feature - Introduce an option where Auto-Scaling Droplet Pools can use a single shared storage backend: * One centralized SSD storage layer * Read-Write-Many capability * Low latency, optimized for web hosting * Elastically resizable (adjustable capacity) * Managed & fault-tolerant From a customer perspective: > “Create an auto-scaling pool where every droplet shares the same SSD, instead of each droplet having its own independent disk.” We don’t need to define the internal technology - just the capability. --- Ideal Stack - When paired with: * DO Load Balancer * Managed Database This enables: Load Balancer | Auto-Scaling Web Pool | Shared Elastic SSD Storage | Managed Database --- Why This Matters - This allows users to: * Run real HA WordPress / WooCommerce * Build scalable hosting businesses on DO * Avoid Kubernetes for simpler stacks * Support large concurrency safely * Stop leaving DigitalOcean to AWS / GCP for storage needs Summary - DigitalOcean users need: > Auto-Scaling Pools + Shared Elastic SSD Storage This unlocks modern, scalable, reliable hosting without complex custom storage infrastructure.

When creating Access Key with Limited Access for specific bucket, that bucket is unable to setpolicy via s3cmd. Only full access one can be used with setpolicy function via s3cmd. This expose to much permissions when we have multiple buckets for multiple projects or multiple clients. Please allow us to setpolicy on bucket that have Limited Access Key.

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.

I've got Spaces buckets configured via CDN. When a user goes to the CDN hostname of the bucket without any real file request it will get a general access denied response. But that response reveals the bucket name. That can be a security risk as it sometime ties into application names or references to other hostnames you're using in the system. No reason to reveal that info to someone requesting the main url for no legit reason. The bucket name should not be included in the access denied response or it should be a config setting you can disable/enable.

Currently there is the option for spaces access keys to either be fullaccess or read/write/delete scoped on one or several buckets. An access key which has read on a bucket still can't do something like "s3cmd info s3://<bucket-name>". Ideally there is something like a fullread key that allows reading all the information in Spaces.

I have to move one of my projects out of DigitalOcean because Volume Block Storage is too expensive. Competitor: 1,000gb HDD block storage is $25 / month. Digital Ocean: 1,000gb NVMe block storage is $100 / month. ^ This is a $900 / year difference. Notes: The competitor also offers NVMe block storage at the same price as Digital Ocean. Block storage is a specific requirement, object storage (DO Spaces) will not work for this project.

Currently, to use a custom domain with DigitalOcean Spaces CDN (e.g., cdn.example.com pointing to my-space.fra1.cdn.digitaloceanspaces.com ), I need to transfer my entire domain's DNS management to DigitalOcean nameservers. This is problematic because: Many users prefer managing DNS with Cloudflare for better performance, DDoS protection, and advanced features Domain consolidation - users want to keep all domains in one DNS provider Current workarounds are complex - requiring Workers, redirects, or proxies that break the user experience Proposed Solution: Allow custom domain verification through: DNS TXT record verification (like most CDN providers) CNAME verification method File-based verification on the domain Benefits: Users can keep their preferred DNS provider Simpler setup process Better user experience with branded CDN URLs Competitive with other CDN providers (Cloudflare, AWS CloudFront, etc.) This would make DigitalOcean Spaces more competitive and user-friendly for developers who want branded CDN URLs without the complexity of full DNS migration.

We would like to ability to replicate a space / bucket between regions. I see two ways this could be implemented. Since a Space name is globally unique. You could have an option to host that space in xxxx locations and have data automatically replicate to each region. Allow the user to choose two or more spaces in any region to create a replication rule. I think there should also be two modes, master/slave and master/master. Replication should be automatic and fast. In master/slave all changes created on one space / region would replicate to the other region but not vice versa. Where as with master/master changes made in either space will be replicated to all other spaces in the replication pool.

Currently the Graphs do not display disk utilization for attached volumes. This should be added.