Core Compute Platform

Currently, DigitalOcean does not allow rebuilding a Droplet using a snapshot or image that belongs to a different operating system family (for example, migrating from Debian to Ubuntu). This limitation prevents users from upgrading or switching the OS on an existing Droplet without losing its assigned public and private IP addresses. For many production environments, keeping the exact same IP addresses is critical due to integrations with customers, vendors, firewalls, allowlists, licensing systems, and legacy configurations that cannot be changed easily or quickly. The recommended approach—creating a new Droplet with the desired OS and migrating data manually—forces the allocation of new IP addresses. In many real-world scenarios, changing IPs is not feasible and would cause service disruptions. We request the introduction of a feature that would allow: Rebuilding an existing Droplet using a snapshot or image from a different OS family, without requiring the creation of a new Droplet. Preserving both the current public and private IP addresses during the rebuild process. Alternatively, enabling a full OS reinstallation on the same Droplet (even across OS families) while keeping the same IPs. Why this is important: Many systems rely on fixed IPs for authentication, VPN tunnels, firewall rules, and client integrations. Migrating from Debian to Ubuntu or other distributions is a common and legitimate need when upgrading to more recent OS versions. The current limitation forces unnecessary redesigns of infrastructure solely due to OS changes. This feature would allow major OS upgrades with zero impact on external systems that depend on the Droplet’s IP. Expected impact: Reduced migration and maintenance effort. Elimination of forced IP changes. Increased flexibility in Droplet lifecycle management. Simplified modernization of legacy systems without downtime. This feature would greatly benefit teams that require strict IP continuity while maintaining or upgrading their Droplet operating systems.

I’d like to suggest that DigitalOcean add support for ARM64-based droplets. Justification: ARM64 (aarch64) architecture has become increasingly popular due to its energy efficiency, lower cost, and growing ecosystem support across major cloud providers. Many modern workloads, including containerized applications, serverless platforms, and edge computing, are optimized for ARM64. Adding ARM64 droplets would: • Reduce infrastructure costs through improved performance-per-watt. • Enable users to test and deploy ARM-compatible software natively. • Increase competitiveness with other cloud providers (e.g., AWS Graviton, Azure ARM, GCP Tau T2A). Expected Outcome: Provide users with the option to create ARM64 droplets alongside existing x86-64 ones, including compatible images and SDK support via the API.

I would like to suggest that DigitalOcean consider migrating its virtual machine infrastructure from Legacy BIOS to UEFI boot mode. This transition could offer significant benefits in terms of performance, enhanced security features, and broader compatibility with modern operating systems. UEFI provides faster boot times, support for larger disk sizes via GPT, and more advanced security measures such as Secure Boot, which helps prevent unauthorized or malicious code from running during the startup process. As more distributions and enterprise environments are shifting towards UEFI by default, this move could future-proof DigitalOcean’s platform and provide users with a more robust and secure experience.

Cloud platforms like AWS/Azure have a concept of spot instances, where you can get unused compute capacity at discounts up to 90% in some cases, with the acceptable downside of that instance getting terminated at any time. Can spot instance concept be supported on DigitalOcean as well?

If you have MySQL with master-slave setup and both are on the same physical host, you're totally screwed when there is a hardware failure - both master and slave are dead and there's no point in even doing replication. Or, if you have 2 Rails application servers and they are on the same host, it's an SPOF. In other words, whenever you have multiple droplets in a project, you need to confirm if any combination of droplets are on the same host or not. Right now, we have to write a support ticket to confirm if those droplets aren't on the same host. But it's been quite a hassle to do so, as all of our servers need such a redundancy. It would be great if there's a self-service way to verify that ourselves. Or better yet, offer a way to explicitly create a droplet on a different host. Right now, some customers might be at risk that unknowingly have multiple droplets on the same host and learn the hard way when it goes down, that it had been an SPOF. Nobody wins from this. This feature will save time for both customers and DO support staff. Win-win. For the record, Linode offers this by showing the host name (like newark313) on the dashboard.

Give option to purchase VPS for long term like months, years like linode does.

We can resize our droplet by just shutting down it , but it will more exiting if we can resize our droplet without shutting down.

I would like to request the ability to increase only the disk size of a droplet, without having to scale up CPU and RAM. In my case, I run a MySQL cluster that’s highly sensitive to storage latency. I originally used block storage volumes (which I could expand easily), but I experienced latency issues and was advised by the DigitalOcean team to migrate to Premium Intel droplets with local disks to improve performance — and that worked perfectly. Now, however, I’m running out of disk space again, and the only way to expand it is by upgrading to a higher droplet tier that doubles CPU and RAM, which I don’t need. This limitation creates unnecessary cost and resource waste for workloads that are I/O-bound, not CPU- or RAM-bound. Having the option to expand local disk independently (even as a paid add-on or tiered option) would be extremely valuable for database-heavy applications like MySQL, PostgreSQL, or Elasticsearch clusters. Thank you for considering this — it would make DigitalOcean much more flexible for production workloads that depend on local storage performance.