User Interfaces

It would be sick if it were possible to have systems be automatically bootstrapped with Chef upon creation. e.g. Users could set up recipes and roles in the DO control panel somehow, and then pick a role to automatically create a Droplet from. Additionally, users could share their Chef stuff with each other, which would allow everyone to benefit from the magical auto-provisioning. And, it's more transparent than allowing users to share pre-built images, since anyone can inspect the code for the Chef recipes before using them to provision a Droplet. Or, even better than managing Chef stuff through the DO control panel, it would be great if I could just give a URL to a GitHub repo containing the recipes/roles, and then the Droplet would automatically pull down this repo and bootstrap itself with the desired role(s).

Support Juju. https://juju.ubuntu.com/ This will make deploying new services easier so that devs can focus on their software instead of setting up a server.

The reset root password api method send by email the new droplet root password to the digitalocean client email. If you are reselling digital ocean vps your client have no way to know the root password. The "reset root password" should return the new root password instead of just an sucessful answer.

Be able to transfer droplet snapshots from user to user via the api. The functionality exist on your platform, so why not release it as apart of the v2 api?

Hi! I work at Doppler and we're interested in creating an integration with App Platform. Unfortunately, we require API endpoints for managing environment variables to do so (create, update, delete, and optionally get). So! We're hoping you might consider adding API endpoints to manage those.

It would be nice to have webhooks whenever certain events occur, to help automate certain tasks. Examples of such events are: Kubernetes node added Kubernetes node removed Kubernetes node recycled Droplet created Droplet removed Droplet recycled I'm sure there are other helpful examples. Monitoring is something that could also take advantage of this.

I think it is great that Digital Ocean rolled out it's beta testing to provide custom scopes for personal access tokens shown here: https://docs.digitalocean.com/reference/api/create-personal-access-token-with-custom-scopes/ However, I think it is missing one hugely beneficial feature that could dramatically increase security in the event of a compromised token. There should also be an option to allow tokens to only be used by authorized IP addresses and/or IP ranges. This way, attackers cannot use a compromised token to destroy resources regardless of customized granularity. It's a secondary protection layer to provide much stronger security. Default setting should of course be to allow all IP ranges, but if a token grantor wishes to have greater security, allow them the option to limit it only to authorized IP addresses (ie. the IPs of their droplets or other resources from where they anticipate making the API calls). The token-creator should be able to customize that IP list and/or IP range(s) accordingly.

The scoped API is great, and the access control on the cloud platform greatly improves. It would be even better if this can be automated programmatically. This can e.g. facilitate the microservice architecture, to delegate down-scoped access to another service (especially for a short period of time). The tokens currently are all created manually by hand, and are only usable in trusted environments (with a permanent or very long token expiration until you manually rotate them).

It would be beneficial to retrieve regional latency metrics via the API for the following locations: Europe Asia East USA East USA West As previously mentioned, since the data is already stored for 90 days, it would be ideal to have the ability to consistently fetch the most up-to-date latency information from each region to our services.

It would be helpful if the DigitalOcean API allowed specifying a service account when getting Kubernetes credentials and kubeconfigs.