DigitalOcean Volumes Guide 2026 — Block Storage for Scaling

A practical guide to DigitalOcean Volumes block storage covering pricing, attaching, mounting, resizing, and snapshots for developers.

When the SSD space that comes with a Droplet isn't enough, instead of resizing the entire Droplet to a more expensive plan, DigitalOcean Volumes is independent block storage that can be attached to any Droplet via DigitalOcean's internal network on demand. This article walks you through the concepts, pricing, creation, attachment, mounting, formatting, all the way to resizing and snapshots, complete with real doctl commands ready to use immediately.

What are Volumes? How They Differ from Droplet Disk

DigitalOcean Volumes is an SSD-based block storage service that is completely independent of Droplets. It connects to a Droplet via DigitalOcean's private network—not a disk physically inserted in the machine. The key difference from Droplet disk (the disk that comes with a Droplet plan) is that Droplet disk is bound to a Droplet for its entire lifecycle, with a fixed size depending on the plan you choose, such as the $6/month Droplet Basic plan (1 GiB RAM, 1 vCPU) comes with 25 GB SSD, the $12/month plan (2 GiB RAM) comes with 50 GB, the $24/month plan (4 GiB RAM, 2 vCPU) comes with 80 GB, and if you delete the Droplet the data on that disk is gone instantly. In contrast, Volume is an independent resource with its own lifecycle. It can be created separately, attached to any Droplet in the same region, detached and re-attached to a different Droplet, and even if you delete the Droplet that is using it, the Volume persists with all its data intact until you explicitly delete it. This concept is similar to AWS's EBS or Google Cloud's Persistent Disk—it separates compute from storage so you can scale or move data without affecting the Droplet itself. The main reason developers choose Volumes over upgrading the entire Droplet plan is the scenario where CPU/RAM is already sufficient but you need more storage capacity. For example, storing user-uploaded files, storing a database's data directory, archiving long-term logs, or serving as media storage for a web application. Separating Volumes from the main disk also makes it clearer to plan backup and storage scaling independently from compute planning.

• Volumes are independent SSD-based block storage connected to Droplets via private network
• Droplet disk has a fixed size per plan, e.g., $6/month=25GB, $12/month=50GB, $24/month=80GB, and vanishes when you delete the Droplet
• Volumes have their own lifecycle—delete the Droplet and the Volume remains until you explicitly delete it
• Can be attached to a Droplet only in the same region

Pricing: $0.10/GiB per Month

Worth highlighting here — digitalOcean charges Volumes at $0.10 per GiB per month, with billing calculated based on actual usage prorated hourly, just like Droplets. This means if you create a 100 GiB Volume the cost is approximately $10 per month, if you create 500 GiB it's approximately $50 per month, and if you create 1,000 GiB (1 TiB) it's approximately $100 per month. This rate is fixed and does not vary by region, and is itemized separately from Droplet costs but shown together on the same invoice. A cost consideration to keep in mind is that Volumes start incurring charges the moment creation completes, regardless of whether it's attached to a Droplet yet. And charges continue even if the Volume is detached from its Droplet. So if a Volume is no longer needed you should delete it to stop incurring charges, as the system won't auto-delete it. Another point to plan ahead is that Volumes can be expanded in size later, but cannot be shrunk. So estimating the initial size as close as possible to actual needs helps control costs better than creating oversized Volumes preemptively. For teams needing budget projections, verify the current pricing directly from DigitalOcean's website since the figures in this article are from July 2026.

• Fixed rate of $0.10 per GiB per month, billed prorated hourly
• Examples: 100 GiB ≈ $10/month, 500 GiB ≈ $50/month, 1,000 GiB ≈ $100/month
• Itemized separately from Droplet billing but shown on the same invoice
• Charges begin immediately upon creation, even if not yet attached or already detached
• Data as of July 2026—verify current pricing from the provider before budgeting

Create and Attach Volumes to Droplets

Creating a Volume can be done two ways: through the Control Panel web interface and via the doctl command for automation. On the Control Panel, go to the Volumes menu, select Create Volume, specify the size, choose a region matching your Droplet (because Volumes can't be attached across regions), choose a filesystem you want the system to auto-format (ext4 or XFS), and select the destination Droplet to attach it in one step. For the CLI route, use doctl compute volume create data-volume-01 --region sgp1 --size 100GiB --fs-type ext4 to create a 100 GiB Volume in Singapore region pre-formatted as ext4. Then attach it to a Droplet with doctl compute volume-action attach <volume-id> <droplet-id>, where you need to look up the volume-id and droplet-id first using doctl compute volume list and doctl compute droplet list. One constraint to be aware of is that a Volume typically is designed to be attached to one Droplet at a time, not shared storage that multiple Droplets can access concurrently. If you need multiple Droplets to access the same file set simultaneously, consider Spaces Object Storage or Network File Storage instead. Volume naming should be descriptive—include environment and region in the name, such as db-data-prod-sgp1 to make management easier when you have multiple Volumes in the same account. And always verify the region matches your Droplet before clicking create, because this is a required constraint that can't be changed later without snapshots.

• Must create the Volume in the same region as the Droplet you'll attach it to
• Control Panel lets you choose filesystem format (ext4/XFS) and attach a Droplet in one step
• Create command: doctl compute volume create <name> --region <region> --size <size> --fs-type ext4

Mount and Format on Linux

After attaching a Volume to a Droplet, the operating system sees it as a new block device, but you must mount it yourself before using it. SSH into the Droplet and check the device with lsblk or view it via ls -l /dev/disk/by-id/, which shows names in the format scsi-0DO_Volume_<volume-name>. Using the path from /dev/disk/by-id/ instead of referencing /dev/sda or /dev/sdb directly is critical, because device names like sdX can shift after reboot if you have more than one Volume. If you created the Volume without having the system auto-format it, you must format it first with sudo mkfs.ext4 -F /dev/disk/by-id/scsi-0DO_Volume_data-volume-01 (or mkfs.xfs for XFS), running this command only once on a blank Volume. Never re-run it on a Volume that already has data because it will erase everything. Then create a mount point with sudo mkdir -p /mnt/data-volume-01 and mount it with sudo mount -o discard,defaults /dev/disk/by-id/scsi-0DO_Volume_data-volume-01 /mnt/data-volume-01. Mounting this way disappears after a Droplet reboot, so add it to /etc/fstab to auto-mount on every boot, adding a line like /dev/disk/by-id/scsi-0DO_Volume_data-volume-01 /mnt/data-volume-01 ext4 defaults,nofail,discard 0 0. The critical point is always including the nofail option to prevent the Droplet from hanging in emergency mode if the Volume is detached or temporarily unavailable on boot. The discard option helps the filesystem support TRIM commands for SSD-based storage. After editing fstab, test with sudo mount -a before rebooting to ensure there are no syntax errors.

• Check the device with lsblk or ls -l /dev/disk/by-id/ before mounting
• Format for the first time only with mkfs.ext4 or mkfs.xfs on a blank Volume
• Mount with mount -o discard,defaults /dev/disk/by-id/... /mnt/...
• Add to /etc/fstab with options nofail,discard for auto-mount on reboot safely

Resize and Move Volumes Between Droplets

From our hands-on testing — when a Volume starts running out of space, you can expand its size both from the Control Panel and via doctl compute volume-action resize <volume-id> --region <region> --size <new-size>. A critical constraint is that resize only goes in one direction—you can only expand, never shrink a Volume. If you truly need a smaller Volume you must create a new one and migrate the data yourself using tools like rsync. When DigitalOcean resizes, it expands only the block device itself; the filesystem inside won't recognize the new space until you explicitly tell it to. For ext4, run sudo resize2fs /dev/disk/by-id/scsi-0DO_Volume_data-volume-01, or for XFS use sudo xfs_growfs /mnt/data-volume-01 (note: XFS takes the mount point, not the device path). If you skip this step the new space won't be usable even though the resize succeeded. To move a Volume to a different Droplet, first detach it from the old Droplet using doctl compute volume-action detach <volume-id> <droplet-id>, then attach to the destination Droplet in the same region. All data transfers intact. But if you need to move across regions directly it's not possible because Volumes are bound to the region they were created in. The workaround is to snapshot the original Volume first, then use that snapshot to create a new Volume in the destination region. Plan the detach/attach window in advance because applications using the Volume data won't be able to access it while it's unattached.

• Resize only goes up, never down
• After resize, run resize2fs (ext4) or xfs_growfs (XFS) to expand the filesystem to match the new size
• Move a Volume between Droplets by detaching first then attaching to the new machine
• Cross-region moves require creating a snapshot first, then a new Volume from that snapshot in the destination region
• Plan the detach/attach window in advance since the Volume is inaccessible during the move

Volume Snapshots: $0.06/GiB

A Volume Snapshot is a point-in-time copy of a Volume's data, kept for backup or later cloning into a new Volume. Snapshots are billed separately from active Volumes at $0.06 per GiB per month, cheaper than the active Volume rate of $0.10 per GiB per month, making long-term backup storage via snapshots more cost-effective than keeping standby Volumes. Create snapshots via the Control Panel on the Volume page by clicking Take Snapshot and naming it, or automate with doctl compute volume snapshot create <volume-id> --snapshot-name data-volume-01-2026-07-17. For automation via scripts or cron jobs, always include a timestamp in the snapshot name so you can easily manage retention and review history when snapshots accumulate. Once you have a snapshot, create a new Volume from it using doctl compute volume create data-volume-restored --region sgp1 --size 100GiB --snapshot-id <snapshot-id>, which gives you a new Volume with identical data to the source snapshot. This works for restoring after a failure, cloning data to another Droplet for testing, or migrating a Volume across regions as mentioned earlier. A best practice is to snapshot before risky changes like database version upgrades or large migrations, so you have a clear rollback point if something goes wrong.

• Snapshot pricing is $0.06 per GiB per month, cheaper than the $0.10 per GiB for active Volumes
• Create via Control Panel or doctl compute volume snapshot create
• Use snapshots to create new Volumes with doctl compute volume create --snapshot-id
• Clone data across Droplets or migrate Volumes across regions
• Snapshot before risky operations like database upgrades or large migrations as a safety net

Common Mistakes and How to Fix Them

The most common mistake is forgetting the nofail option when adding a Volume to /etc/fstab. The consequence is that if the Volume is detached for any reason or has a temporary connection problem on boot, the Droplet will hang in emergency mode and fail to start normally. Prevention is simple: always include nofail in every fstab entry you add. The second mistake is referencing devices by name directly like /dev/sda or /dev/sdb instead of using paths from /dev/disk/by-id/. With multiple Volumes attached to one Droplet or repeated detach/attach cycles, the sdX device names can shift after reboot, causing you to mount the wrong Volume and risk accidentally overwriting data. The third mistake is not monitoring available space on the Volume. This leads to disk suddenly running full with no warning, causing applications to fail writing files or databases to stop working. You should enable a Monitoring Agent and set up Alert Policies to notify you when space usage approaches capacity so you can plan a resize in advance. The fourth mistake is trying to attach a Volume to a Droplet in a different region, which always fails because Volumes are bound to the region they were created in. And the fifth common mistake is misunderstanding that resize can shrink a Volume, when it only expands. If you truly need to shrink you have to create a smaller Volume and migrate the data manually with tools like rsync.

• Forgetting nofail in fstab → Droplet won't boot if Volume detaches or has connection issues
• Using /dev/sdX directly instead of /dev/disk/by-id/ → mounts wrong device after reboot
• Not monitoring free space → disk fills suddenly with no warning

Best Practices

For production workloads, always separate data Volumes from the Droplet's main OS disk so you can backup, resize, or move data independently without impacting the Droplet's operating system and configuration. For example, keep a database's data directory on a separate Volume while the OS and application live on the main disk as usual. Name and tag Volumes clearly to indicate their purpose—include environment (dev/staging/prod) and region in the name, making it easier for your team to manage many Volumes in one account and reducing the risk of accidentally deleting or detaching the wrong one. On the backup side, set up automatic snapshot schedules via cron jobs calling doctl compute volume snapshot create regularly—daily or weekly depending on data importance—and establish a retention policy to delete old snapshots you no longer need to control costs, since snapshots bill continuously by size just like Volumes. Enable a Monitoring Agent on your Droplet and configure Alert Policies to notify you when Volume space usage nears capacity so you can plan a resize ahead of time before problems occur. Also avoid placing swap files on Volumes because the network latency of the internal connection is higher than local disk, making it unsuitable for the high random access speeds swap demands. Lastly, periodically test your restore process from snapshots even without an emergency to ensure snapshots actually work when you need them, and keep documentation mapping Volumes to their Droplets so your team can find this information easily as you grow and accumulate more Volumes.

• Separate data Volumes from the OS disk on production systems
• Name and tag Volumes to show environment and region clearly
• Set up automatic snapshot schedules with cron + doctl and define a retention policy
• Enable Monitoring Agent and Alert Policies to warn when space is nearly full

Get $200 Free Credit →