DigitalOcean Droplets Explained: Plans, Images and Limits

What a Droplet is actually made of

A Droplet is DigitalOcean's virtual machine, and the name is doing real work. It suggests something small, self-contained and quick to create, which is exactly the product philosophy. Creating one takes a plan, a region, an image and an authentication method, and that is genuinely the whole list.

Underneath, a Droplet is a KVM virtual machine with a fixed allocation of vCPU and memory, an SSD or NVMe system disk sized by the plan, one public IPv4 address, an optional IPv6 address and an interface on a private VPC network in its region. It boots from an image and can run a cloud-init script on first start.

Everything else, block storage volumes, object storage, managed databases, load balancers, firewalls, is a separate resource you attach or point at it. Understanding that separation makes the rest of the platform predictable: the Droplet is compute, and compute alone.

Plan families and who each one suits

The plan decides two things at once: how much CPU and memory you get, and whether that CPU is shared with other tenants or dedicated to you. That second distinction matters more than most newcomers expect.

Shared CPU plans are excellent value and perfectly production-worthy for many workloads, but they are subject to the usual noisy neighbour dynamics and DigitalOcean applies fair-use expectations to sustained full utilisation. If a service pins its cores for hours at a time, a dedicated family is the honest choice rather than a luxury.

Not every plan exists in every region, and the newest families reach some datacenters before others. Check availability in the region you want before designing around a specific shape, a habit worth keeping on any provider as discussed in picking a cloud location.

Four ways to start a Droplet

Distribution images

Clean installations of the mainstream Linux distributions, maintained by DigitalOcean and updated regularly. This is the right starting point when your configuration is handled by a provisioning tool rather than baked in.

Marketplace one-click applications

Pre-built images with software already installed and configured, covering application stacks, control panels, databases and development tooling. They are a fast route to a working environment, and the tradeoff is that you inherit somebody else's configuration decisions along with the convenience.

Custom images

You can upload your own disk image in several common virtual machine formats and boot Droplets from it. This is the path for teams migrating an existing golden image or running a distribution DigitalOcean does not publish.

Snapshots and backups

A snapshot is a manual point-in-time copy of a Droplet's disks that you can restore or use as a template for new Droplets. Backups are the automated equivalent, enabled per Droplet as a paid add-on on a schedule. Both are stored as separate resources and are billed for the capacity they occupy, so retention deserves a policy rather than good intentions.

Because snapshots double as templates, the usual workflow is to build once, snapshot, and then create from the snapshot. Pair that with a first-boot script for the parts that must be unique, as described in cloud-init for server provisioning.

Resizing, and the one-way door

Droplets can be resized, and there are two kinds of resize with very different consequences. Understanding the difference before you need it prevents an unpleasant discovery later.

A CPU and memory resize keeps the disk size unchanged. It requires the Droplet to be powered off, takes a short time, and is reversible: you can move up for a busy month and back down afterwards.

A resize that also increases disk size is permanent. The disk grows, and from that point you cannot scale the Droplet back down to a plan with a smaller disk. If you expect load to fluctuate, choose the CPU and memory resize and keep bulk data on a separate block storage volume, which can be resized independently and detached entirely.

That pattern, small system disk plus attached volume for data, is the single most useful habit on this platform. It keeps the compute layer disposable and makes rebuilds cheap.

Limits, allowances and things that still bill

Every account carries a Droplet limit, a cap on how many you may run at once. New accounts start with a modest figure, and the limit is raised through a support request once there is a track record. The current value is shown in account settings, and it is worth checking before planning a deployment that creates many machines at once.

Data transfer works on a pooled allowance. Each Droplet contributes an amount of outbound transfer to an account-wide pool, and usage is measured against that pool rather than per machine, with overage billed beyond it. Inbound traffic is not counted. The practical effect is that one busy Droplet can draw on the allowance contributed by quieter ones, which is unusually forgiving compared with metered providers.

Snapshots, volumes, reserved IP addresses that are not attached to anything, and load balancers are all separate billable resources that outlive the Droplet they were created for. A monthly sweep for orphans is a small habit with a real payoff.

The network around a Droplet

Each region has a default VPC network, and Droplets created there receive a private interface on it automatically. Traffic between Droplets over that private network does not consume the public transfer allowance, so internal service-to-service calls and database connections belong there rather than on public addresses.

Cloud Firewalls are applied at the network edge rather than on the machine, filtering before packets arrive. They attach to Droplets by tag, which means a new Droplet created with the right tag inherits the correct rules at birth. That is a much better pattern than configuring rules per machine.

Reserved IP addresses are static public addresses that can be moved between Droplets in the same region. They are the building block for a simple failover arrangement, explored further in floating IPs and failover on developer clouds. IPv6 can be enabled for a Droplet as well, giving it a routed address alongside its IPv4.

doctl in practice

The DigitalOcean CLI is doctl, and it mirrors the API closely enough to be a good exploration tool. Authenticate once with a personal access token, then inspect what is available:

doctl auth init

doctl compute size list

doctl compute image list-distribution --public

doctl compute ssh-key list

Creating a Droplet is a single command, and passing a cloud-init file keeps first-boot configuration in version control rather than in somebody's shell history:

doctl compute droplet create web-01 --region fra1 --size s-2vcpu-4gb --image ubuntu-24-04-x64 --ssh-keys $FINGERPRINT --vpc-uuid $VPC --user-data-file ./cloud-config.yaml --wait

Useful follow-ups include doctl compute droplet list --format ID,Name,PublicIPv4,Status for a quick inventory and doctl compute firewall list to confirm which rules apply. DigitalOcean documents the full surface in its Droplets product documentation.

Key takeaways

• Shared CPU plans suit variable workloads; dedicated families are the honest choice for sustained full utilisation.
• Keep the system disk small and put data on a block storage volume, so CPU and memory resizes stay reversible.
• Transfer allowance is pooled across the account and inbound traffic is free, which makes bills unusually predictable.
• A powered-off Droplet still bills. Snapshot and destroy to actually stop charges.
• Attach Cloud Firewalls by tag and keep internal traffic on the VPC network rather than on public addresses.

For how the platform stacks up against its closest rivals, see the DigitalOcean and Vultr comparison and the DigitalOcean and Hetzner comparison. The equivalent orientations for those platforms are Vultr cloud compute plans and Hetzner cloud servers and projects, and the DigitalOcean account listings describe the options on offer.