Reserve IP Addresses / Make sure we can keep an IP if we recreate a droplet.
When destroying a droplet there's a 99% chance that you will get your IP back. If someone creates a droplet while destroying/creating a new one and steals your IP, it's a pain, even if the chances are <1%.
This 1% is too much for some. An IP is an important number, your server might not be able to send emails if the last IP's user was sending spam through it.
Software licenses are also tied to IP sometimes.
When I want to rebuild a server (or resize: disk size) I want to make sure that I get my IP back.
Please figure out a way so that we don't lose our IP (100% guaranteed) when we destroy/recreate a droplet.
During the droplet creation wizard, you should let users have more control over what kind of IP connectivity they need.
Not every user needs an externally facing IP address if their droplet is for internal use only.
Some users might use Cloudflare's IP6 to IP4 proxying ability and don't need an IP4 address.
Some users might need more than 1 IP4 address
Some users might need 100 IP6 addresses
By giving this control, you can free up unused IP4 addresses, a valuable commodity, and free up one expense that you can pass onto the users.
I have faced a trouble by being assigned of the same range of IP addresses every time I create my droplets.
Many of the IPs have been banned from access from Russia, and as I result my domain name became to be part of such blacklist.
To deal with the situation I have created 10 more droplets and have been forced to keep them in order to receive fresh IP address. This is not very convenient and pricy.
I propose DigitalOcean will offer range of IPs or even create a service for "fresh never used before IP addresses" for a couple extra dollars a month.
Edward, our new Director of Customer On Boarding, has been reaching out to a number of customers to see what we can do improve the service. The request to be able to reserve an IP address came up from many customers, and has also received tremendous support from the community with the number of votes that it received on UserVoice.
As we’ve scaled out the engineering team we have a large number of projects that are currently in traction along with some that we’ve already launched like the new API v2, IPv6, and so forth, but given the huge amount of support for this request, we are going to try and slide this into the roadmap earlier at a higher priority.
For that we’ll be doing some initial testing to see how we can work this into the existing product set, how much engineering time that will take, and see who on the engineering team can be pulled for this project so that we can ship it sooner.
As soon as we get out of the planning and architecting phase we’ll move this over to “Started”, which means we’ve begun writing code for this feature.
Alfonso Urdaneta commented
In desperate need of an update for this one. Thanks.
any update or ETA ?
Would it be possible to get an update/ETA on this?
We got stung by this very issue tonight while resizing a droplet to the next size up, due to having to perform the droplet resize work-around; once back after a ~47minute snapshot (~53minutes for one previous a few days prior) and a 25minute create, amounting to well over an hour downtime for a production site just for a change in server capacity which is supposed to take...far less time according to the fast resize option... Ok, so fair enough, we have a 60GB disk at ~50% capacity, so that's gotta take some time, just no way around that, Ok, I can deal with that, that's just the way things are...but then we get back up and we've lost our IP and are facing more downtime still while DNS propagates... ok stuff happens, you guys are still ramping up features working out kinks and putting together the best service you can for your customers based on the needs they have, and putting together an otherwise really fine service too I must say, we're otherwise really happy with everything you guys are doing and understand there are hiccups along the way, but we're now on the edge of having to move elsewhere for business risk reasons due to this occurring as we have investors to answer to - I understand things sometimes don't work perfectly, but please allow us a safety net for when they don't, the occurrence of an "unfortunate series of events" so to speak of a few things not-going-quite-right can really ruin someone's day. Please help us stay with you guys, we love what you're building, but no doubt you understand what the "beancounters" can be like.
+1 on this. Especially since at the moment the only way to add disk space to your server is to (re)create. Not having this feature is actually stopping us from upgrading servers with DO (and therefore spending more money with them).
Alex Potter commented
Is there any news on this? Given the current DNS propagation issues this would be an extemely useful addition to the service.
Gustavo Moura commented
At least if you keep that ip reserved until we launch a new droplet, don't need to last forever but as Dries says, have a peace in mind that we will get that particular IP again
Have notice that when I launch a new droplet I get my ip back and that is awesome... but what if I don't? :'c
Thanks for the efforts!
Thank you! This worried me when I made a new droplet. Some things like TeamSpeak NPL licences are locked to IP and it can take a very long time to get in contact to swap licenses around.
What you could do is provide a mandatory choice at deletion time where we select if we wish to keep the IP of the droplet and inform us it will be reserved for X days. Then when we create a new droplet, if there are unused reserved IP's on our account we can choose which IP to assign to the new droplet during the creation or a second step after it.
Kerem San commented
This is great news!!! Kindly ensure to include the Private Network IP along with the more visible Public IP in this reserved IP provisioning. Thank you very much for your efforts.
it is very important. +3 votes.
Dirk Luijk commented
Yes, especially for IP-tied licenses (e.g. DirectAdmin panel software).
IMO This should not be implemented by default. I think DO should offer this as a separate service, allow purchasing IPs (Maybe $1/mo each) that you can apply to droplets if you want.
Generally I do not want to get the same IP again, as reconnecting to SSH flags the server because the fingerprint no longer matches since last connecting to it. I have to go into my known_hosts file and delete it to be able to connect to it again.
Mark K Cowan commented
Regarding my last comment, you can have the TTL usually set at 86400 (one day), but drop to 60 seconds in anticipation of a potential IP-change - then a day later do the re-creation, update the IP, then set the TTL back to 86400.
Mark K Cowan commented
Have a "mission critical" droplet that runs a DNS server :D PowerDNS+PowerAdmin is a nice combination.
You can then set the TTL of your other droplets' A-records to 60 seconds, ensuring that an IP change only causes a minute of outage at the most (on top of the outage caused by destroying/recreating the droplet).
Obviously, the "mission critical" $5/month droplet should never need to be re-created as it only runs simple stuff (mine runs DNS server + email receiver + automated git backups of config from other servers)
Martin Pescatore commented
This is important, can we have some feedback on it?
I voted on this one and the move VM to VM, even though the rebuild option exists now. Rebuild doesn't work if you want to keep a machine running while you set up a new version of it. Just signed up, started a server, then stopped it. Without this feature, there is no true "scaling" since I can't move my public IP around. Sorry DO, without this I can't use you.
+3 this is absolutely necessary.
Ryan Carr commented
As Wayne Hartman has mentioned. So this
Wayne Hartmann commented
+3 if you can add routes to use custom IP blocks. RIPE has already been mentioned. But I personally have a block reserved with ARIN. Please DO, make this happen!
Jon Roket commented
We need this.