DigitalOcean Droplets can be resized up or down, and the process is surprisingly straightforward, but the real magic is that it happens without any data loss.
Here’s a Droplet running a simple Nginx web server. We’ll simulate a spike in traffic and then resize it.
# SSH into your Droplet
ssh root@YOUR_DROPLET_IP
# Install Nginx if you don't have it
apt update && apt install -y nginx
# Start Nginx
systemctl start nginx
# Check Nginx status
systemctl status nginx
Now, let’s create a simple HTML file to see if it’s serving content:
echo "<h1>Hello from my Droplet!</h1>" > /var/www/html/index.html
If you visit your Droplet’s IP address in a web browser, you should see "Hello from my Droplet!". This confirms our Nginx server is running and serving files.
Imagine this Droplet is now handling a surge of traffic. We can simulate this by running a simple load generator. On a separate machine (not the Droplet you’re resizing), run this command:
# Install apache2-utils if you don't have it
# On Debian/Ubuntu:
sudo apt update && sudo apt install -y apache2-utils
# On macOS (using Homebrew):
# brew install apache2-utils
# Run ab (ApacheBench) to generate load
ab -n 1000 -c 100 http://YOUR_DROPLET_IP/
This command sends 1000 requests in total, with 100 concurrent requests at a time, to our Droplet. You’ll see a report of requests per second, latency, etc. If your Droplet is undersized, you might notice increased latency or even some failed requests. This is where resizing comes in.
To resize, you’ll use the doctl command-line tool or the DigitalOcean Control Panel. Using doctl:
First, list your Droplets to get the ID:
doctl compute droplet list
Let’s say your Droplet has ID 123456789. Now, you can resize it. For this example, we’ll resize it from a s-1vcpu-1gb plan to a s-1vcpu-2gb plan.
doctl compute droplet resize 123456789 --size s-1vcpu-2gb --droplet-action resize
When you run this, DigitalOcean initiates a process that involves shutting down the Droplet, reallocating its resources to the new size, and then booting it back up. The key here is that the underlying block storage for your Droplet’s disk is preserved. It’s not a new Droplet being created; it’s the same Droplet with its storage intact, just with more RAM and/or CPU allocated.
After the resize operation completes (which can take a few minutes), you can check the Droplet’s new specs.
doctl compute droplet get 123456789
You’ll see the new "Size Slug" reflected. Now, run the load test again:
ab -n 1000 -c 100 http://YOUR_DROPLET_IP/
You should observe improved performance metrics – higher requests per second and lower latency – indicating the increased resources are being utilized.
The ability to resize also works downwards. If traffic subsides, you can resize back to a smaller, less expensive plan. This flexibility is crucial for managing costs and performance dynamically. The process remains the same: shut down, reallocate, boot up, with your data safely on the persistent block storage.
What often surprises people is that resizing down also preserves data, and the mechanism is identical. The system simply deallocates resources, but the disk image remains untouched. This is a fundamental difference from, say, destroying and recreating a Droplet, which would indeed mean losing all data unless explicitly backed up.
The most critical aspect to understand about resizing is that while your disk data is safe, any data residing solely in RAM (like in-memory caches such as Redis or Memcached if not configured for persistence) will be lost when the Droplet is shut down for the resize. You must ensure such services are configured to persist their state to disk if their data is critical.
Next, you might want to explore automating Droplet resizing based on performance metrics.