When destroy a droplet, system should ask to enter password to confirm before delete it for more safety. Since this is the most important decision.
Please try to provide this, it is a very valuable feature.
Any update on this ? since i feel like its more important.
1. I need to be able to mark production droplet as PROTECTED
2. when I delete a PROTECTED droplet
I would like the following feature to be implemented
- ask for password
- droplet goes offline
- allow 7 days before destroying data and backups
you can also add it as a PAID FEATURE
Any update to this?
There are two similar suggestions, and there are several good ideas, like
1. mark droplet as protected
2. ask for confirmation through email/phone/2fa/etc for protected droplets
3. ask for droplet name for any droplet on delete
I really need this feature. While there are some clones that can be created and destroyed dynamically, I always fear to accidentally destroy my main droplet that has the database!
Any news on this feature? Can I have an invite?
If i could up vote this by 100 more I would!!
This is absolutely needed. I accidentally destroyed the WRONG droplet earlier and safe to say i wasn't too impressed with this, from an 'ease of ability' perspective. Sure, total human error on my part - i'm not blaming DO for this at all. I would like to suggest a small overlay-box stating something like...
"Are you sure you wish to Destroy <droplet name here>?
Please confirm by typing your DO password, and the root password of the droplet."
My .02 on Teams...
While some people will have access to some of the droplets (on a console level), that shouldn't be enough authorization do destroy/rebuild a droplet. So, I believe that asking for BOTH root and the 'Digital Ocean' account password of the person who admins the droplets, should be required at minimum to DESTROY or Rebuild a droplet.
Alternatively, delegated rights would be a better way of handling this, as each team will have a different set of internal guidelines/authorization/change mgmt. policies & procedures, etc...
Long story short.. please password protect the DESTROY and REBUILD commands on the droplets!! :)
Please add a feature like this. I want to be able to "lock" special droplets so I have the option to require password or slider for deleting special droplets. The current design worries me because I do a lot of testing, creating, and deleting droplets, and I don't want to accidentally delete my main droplets.
I Think is Very.. but Very Easy Destroy the Database and your Droplets.
I Suggest put a very security before destroy any Data.
In my case i am testing before migrate mi websites and database.
I saw very eso to Destroy any work.
I installed Cpanel.. and accidentally i Rebuilt Droplet and delete the Cpanel Instalation.
So.. is very important put something for protect any job.
All is distroyed in just 1 Clic .
Brooke, it's been 8 months since your last update. Can we get another update? I really want to know that my droplets are protected against far-too-easy deletion.
This feature should be limited to droplets we have declared as "protected" or "locked". Otherwise it could become an obstacle.
So, I just accidentally rebuilt a production server. I definitely should have been more careful, but it seems that it would be prudent to have one extra click required confirming that the user actually wants to completely trash their droplet and rebuild it. Would have saved me a heart attack. Very thankful backups have been reliable.
only password is not enough. Because I have few droplet. I an delete wrong droplet. so, we must write, droplet's name.
Droplet destroying process is open for wrong process...
You can verify via text like 'Write this: "Delete "name" droplet"' like security features.
Because I have few droplets and I can delete wrongly.
My previous suggestions should apply to both "production droplets" and also to "production snapshots" i.e. deleted snapshots which are tagged as "production" snapshot should be made available to the user for the next 30 days after deletion.
One way to do this would be to allow a droplet to be tagged/locked as a "production" droplet.This process should be irreversible.
If a production droplet is destroyed for whatever reason then the system should take an automatic snapshot before deleting and make the image/snapshot available for the next 30 days (unlike 48 hours right now).
This would help in case where a person loses access to his own account (losing his mobile for example and where it would take more than 48 hours for the new sim card to arrive ).
Please consider keeping the temporary snapshot for more than 48 hours as it takes more time for a sim card to arrive.
I would gladly pay more for a service which would keep my deleted "production" server for 30 days instead of 48 hours.
good idea, on destroy/rebuild people will need to type in their password or 2-fact code etc
Fully agree. As I just requested,
"""I'm scared by the ease with which droplets can be created and destroyed. Up until now I've created and destroyed them for testing purposes, but now I have a real "production" droplet that should definitely not be destroyed.
But I will still continue to create temporary droplets that get destroyed quickly. I'm afraid that someday I just might accidentally destroy the wrong one.
Having an explicit "lock" option on droplets that needs to be turned off before destroying would seem like a good/safe idea."""
We are looking into some lock features for droplets and double verification for destroy and rebuild.
In the meantime though we do have an automated behind the scenes temporary snapshot that we take for droplets that have been alive for longer than 3 days and haven't had a snapshot taken in the last 24 hours.
This way when you issue that destroy the droplet is destroyed and snapshotted.
This snapshot appears in your /images tab.
It resides there until it expires (2-4) days. If you want to keep that snapshot forever until you destroy it, you can just click the icon next to it on the /images and it will convert from a temporary expiring snapshot into a regular one.
You can also launch droplets from either regular or temporary snapshots. However if you launch from a temporary snapshot that snapshot will still eventually expire.
This is a must to add extra step when someone is trying to destroy a droplet. Please consider to add 2FA verification (if enabled) beside password confirmation.
Please. I just accidentally deleted a server on a business Digital Ocean account, and if Digital Ocean didn't keep backups on Droplet Destruction, I would've had to use a two week old backup.
We NEED this feature for security reasons.
@Mathieu Martin: I agree! Something similar to GitHub would be nice, but now using the password. That might not be a good idea, especially for those having strong passwords.
I completely agree with Luis: we need a feature like EC2's "termination protection" that can be enabled per machine.
Or maybe approach this like Github does when deleting a repo: confirm deletion by typing the repo name (in this case it would be the Droplet name).
Another similar option that I like would be having something similar to EC2 "termination protection". Just a attribute you can enable so the interface just doesn't allow you to destroy the server unless you disable that option again.
I think it is an urgent feature !!!!
Seems like a sensible thing to do, especially since (as I understand) backups will be deleted as well when deleting a droplet, so if you did *not* manually create a snapshot, there's no way to restore your server/droplet
Yes that would be a nice security feature...
I second this
Please make it
Would be a great option!
Agreed! I have never liked simple "are you sure you want to do this" questions. I have been conditioned over years to just automatically click that OK button. Asking for a password better communicates the seriousness of destroying a droplet along with all its data.
I would love a multi-step process or secondary password option for deleting a server. If someone gains access to your admin login it would be so simple for them to wipe out your active servers and backup images.
It would also be good to require an additional step to delete a server though the API.
We can fix this by displaying the droplet name in the modal during confirmation.
You won't be notified about changes to this idea.