DigitalOcean alternatives for developers

What DigitalOcean alternatives actually change

Most DigitalOcean alternatives change the bill, not the machine. You get a Linux virtual machine with a public IP, a virtio disk and root access either way, and your kernel does not care whose logo is on the control panel. The differences that decide the choice are the price per GB of RAM, the size of the included transfer allowance and what a byte over it costs, what the disk is really made of, and how much of the stack above the operating system someone else will run for you.

This guide compares on those axes, because a developer can check every one of them from a terminal or from a published price list. It also names the cases where DigitalOcean is the right answer, because a comparison that concedes nothing is an advertisement.

Every price below is a published list price, checked on 5 August 2026. Prices move, and more than one provider here changed theirs during 2026. Pricing structure moves far more slowly, so read the ratios and the billing model first, then confirm today's number on the provider's own page before you commit.

Price per GB of RAM is the number to compare

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

Inside one provider, the price per GB of RAM barely moves. DigitalOcean charges $6.00 per GB on the 1 GB plan and the same $6.00 per GB on the 4 GB plan, which lists at $24.00 a month. Picking a bigger plan at the same provider does not buy a discount, so the plan size is not the decision. The provider is.

Akamai, which now sells what used to be Linode, prices its 2 GB and 4 GB shared plans at $12 and $24, the same as DigitalOcean to the dollar. Its entry plan undercuts them at $5.00. Two companies matching each other exactly is a signal worth reading: that tier is priced against a competitor, not against the hardware, and it will keep tracking that competitor.

The gap opens with providers that build their own datacentres and sell in euro. A Hetzner CX23 gives you 4 GB of RAM for about $6.49 a month, which is $1.62 per GB, close to a quarter of the DigitalOcean rate. That dollar figure is converted from a euro list price, so it drifts with the exchange rate. Hetzner also raised cloud prices during 2026, so older comparison posts quote numbers that no longer exist.

Price per GB of RAM says nothing about the CPU you get. Shared vCPU means the hypervisor schedules your core against other tenants, and the honest check runs on a box you have actually rented:

vmstat 1 10

Read the st column. It counts the percentage of time your vCPU was ready to run and the hypervisor handed the physical core to someone else. A few percent under load is normal. A sustained double-digit number means the host is oversubscribed, and no price per GB makes up for a core you cannot use. Run it at your busy hour, because steal time is a neighbour problem and neighbours have schedules. For the wider picture on what a month of hosting really costs once storage and traffic are added, read what a VPS costs month to month.

What the included transfer really costs

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean includes 1 TB of outbound transfer on the entry plan and bills the overage by the GiB, which works out near $10.00 per extra TB. Akamai includes the same TB and bills roughly half that, about $5.00 per TB. Vultr includes 2 TB at a similar overage rate. Hetzner includes 20 TB and charges about $1.20 per TB after that, which is an order of magnitude apart from the others.

Three structural details matter more than the headline numbers. Inbound traffic is free at all four, so only what you send out is counted. DigitalOcean and Vultr pool the allowance across every server on the account, so one busy machine eats another machine's quota and a fleet of small servers shares one large pool. And traffic between servers over a private or VPC network usually does not count at all, which is why putting your database on the private interface is a billing decision as well as a security one.

None of this matters if you are nowhere near the cap. A blog, an API with JSON responses or a small SaaS will not reach 1 TB in a month. Video, image galleries, game servers, package mirrors and off-site backup targets will. Measure before you assume:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m prints transfer by month, split into received and transmitted. Only the transmitted column is billed. The database starts empty, so the first useful reading arrives a day after you install it, and the first full month arrives a month later. Until then the provider's own bandwidth graph is the only record you have.

Ask one more question that no price list answers: when you pass the allowance, does the provider bill you or throttle the port. Billing costs money. Throttling costs users, at exactly the moment you have the most of them. You want to know which one a traffic spike buys.

NVMe or SATA, and how to check what you actually got

The panel says NVMe. That is a claim about the disks in the host, and your virtual machine may not be sitting on them. Local storage puts your virtual disk on drives inside the same physical machine. Network storage puts it on a separate storage cluster reached over the datacentre network, which is what makes instant resize, live migration and snapshot-in-place possible.

Inside the guest, both look identical:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA and rotational report 0 for anything the host declares non-rotational, so a network volume backed by NVMe reports exactly what local NVMe reports. The value tells you the disk is not a spinning platter. It cannot tell you where the disk lives. Confirming an NVMe disk on Linux goes through the device names and what each one implies.

The test that separates them is latency at queue depth 1, because a single small read has nothing to hide behind. Local NVMe answers from the same chassis. A network volume adds a round trip across the datacentre network to every single read, so its latency floor is higher even when its throughput at deep queue depth looks similar.

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

The first run prints a clat block, which is completion latency. Read the 99th percentile line rather than the average, because the average hides the stalls users feel. The second run prints IOPS= on its summary line. Run both on the provider you have and on a trial instance of the provider you are considering, on the same day, and compare your own two numbers. A published figure from either vendor was measured on a machine you cannot see. Run it three times at different hours as well, because a quiet host and a busy host give different answers on the same plan. Benchmarking a VPS properly covers the method, and what an SSD VPS actually means covers the marketing words underneath it.

Regions: measure the latency, do not read the map

A region list is marketing until you measure it. What a user feels is the round trip from their network to your server, and that depends on the route their packets take, not on the distance on a map. A server 300 km away behind a congested transit link loses to one 1,500 km away on a clean path.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr prints every hop with its own loss and latency, so a 60 ms jump between two hops names the link that is hurting you rather than blaming the destination. Run it from a machine on the network your users are on. Datacentre to datacentre routes are the best routes on the internet, and they flatter every provider equally.

One structural point survives any price change. A provider with a single region on your continent means your disaster recovery plan is a plan to move continents, with the latency that implies. Count the regions you would actually fail over to, not the regions on the page.

Snapshots and backups are a separate bill

Storage add-ons are where a cheap plan gets expensive. DigitalOcean charges $0.06 per GiB per month for snapshots, and prices its automatic backups as a share of the server instead: 20% of the plan price for weekly backups, 30% for daily, with a usage-based option billed per GiB. Both models are defensible and they fail in opposite directions. A percentage price scales with the size of the server, so a large server holding a small dataset overpays. A per GiB price scales with your data, so a small server attached to a large volume overpays.

Ask what a restore costs and how long it takes, because the price of holding a backup is the boring half of the question. Ask whether destroying the server destroys its snapshots too.

Then keep a copy the provider does not control. Provider snapshots live inside the provider's account, so a lost login, a payment failure or a suspended account takes the server and its backups in the same moment. restic backups into storage you own cost a few dollars of object storage, restore onto any provider, and are the thing that makes a migration reversible instead of final.

How much of the stack do you want to run

Providers sit on a line. At one end you rent a machine and run everything on it yourself. At the other you push a git branch and never see a server. Price per GB of RAM is the right comparison only at the first end, because at the second end you are buying labour rather than memory, and labour does not have a per GB price.

Be honest about which end you are on before you compare anything. A managed database at $15.15 a month looks expensive next to a $6 server until you price the hours behind it: replication, failover, point in time restore, minor version upgrades, and the alert that wakes someone at 03:00. If that work is your job, run it yourself and keep the difference. If your job is the application, buying it back is cheap. The managed and unmanaged split decides which column of the price list you should even be reading. If the honest answer is that you want the whole machine and its disks to yourself, that is a VPS versus dedicated server question rather than a provider question.

Where DigitalOcean is the right answer

DigitalOcean wins when you are buying the platform rather than the virtual machine.

• Managed databases. Managed PostgreSQL and MySQL start at $15.15 a month for 1 GiB of RAM and 10 GiB of storage, with extra storage billed per GiB and standby nodes priced per node. Building the same reliability yourself means Patroni or repmgr, a consensus store, a connection proxy and a failover drill you have actually rehearsed. A two-person team cannot maintain that and ship features.
• App Platform. Push a branch, get a build, a certificate and a running service, with no operating system to patch. The cheap VPS version of this product is you, on a Saturday.
• Object storage and load balancers that a mature Terraform provider covers. A fleet you can destroy and rebuild from code is worth more than a lower unit price.
• The company around the product. Published support tiers, a status page with history, and an organisation that will answer a client's security questionnaire. If you resell hosting, that is worth more than a few dollars per GB.

Where DigitalOcean gets expensive is the plain virtual machine, in quantity, with real outbound traffic. That is the exact case an alternative fixes, and it is most of what a self-hosting developer buys.

Migrate to a new provider without downtime

Downtime during a migration comes from one thing: traffic arriving at the old IP after the data has moved to the new one. Every step below exists to make that window short and predictable.

Start with DNS, at least 48 hours ahead of the move. Resolvers cache your A record for the length of its TTL (time to live), so a record with a 24 hour TTL keeps sending users to the old server for up to a day after you change it. Lowering the TTL at cutover does not help, because resolvers already hold the old value with the old expiry attached. Lower it first, wait out the old value, then migrate.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

The first command prints the current TTL in the second column of the answer. Set it to 300 at your DNS provider, then wait longer than the number you just replaced.

Then work in this order.

1. Provision the new server and harden it before anything else lands on it. The first ten minutes on a new VPS covers the part people skip when they are in a hurry.
2. Install the application stack and run a first pass of the data copy with rsync while the old server keeps serving normally.
3. Issue the TLS certificate on the new host now, using a DNS-01 challenge, because an HTTP-01 challenge validates against the IP that DNS currently points at, which is still the old server. A DNS-01 challenge removes that ordering problem entirely.
4. Test the new host before any public change by overriding DNS on your own laptop. Add 203.0.113.20 example.com to /etc/hosts, browse the real site, then delete the line. No user is affected by this test.
5. Deal with the database size question. Under a few GB, a dump and restore fits inside the write freeze. Above that, set up replication from the old database to the new one days ahead and let it catch up, so the freeze covers only the promotion.
6. Freeze writes. Put the application into maintenance or read-only mode. This is the only part users can see, and it should last minutes.
7. Run the final delta: the same rsync again, then the final database sync.
8. Change the A and AAAA records to the new IP. With a 300 second TTL, most resolvers follow within about five minutes.
9. Leave the old server running and reachable for at least a day, because some resolvers ignore short TTLs. If the old application is still writable, late arrivals will write into the wrong database, so point the old host at the new database or return a maintenance page from it.
10. Watch the new server's error rate for a day, raise the TTL back to its normal value, and destroy the old server after a week rather than the same evening.

The copy itself is two commands, each run twice. The file sync:

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a preserves ownership, permissions and timestamps, -H keeps hard links, -AX keeps ACLs and extended attributes, and --numeric-ids stops rsync from remapping user IDs through names that differ between two machines. Run it days ahead, then again during the freeze, when it transfers only what changed.

For PostgreSQL small enough to dump:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

For MySQL or MariaDB:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction takes the dump inside one transaction on InnoDB tables, so the result is consistent and the application keeps writing while it runs. Without that flag mysqldump locks the tables, which means your write freeze started earlier than you planned and you did not choose when.

Two things break outside your servers. A new IP address has no email reputation, so mail sent straight from the new box is filtered as spam: send through a relay that already has a reputation. And any partner that allowlists your outbound IP, such as a payment gateway or a client firewall, must be updated before cutover, or those calls start failing the moment traffic moves.

What to check before you commit

• Whether the price is promotional and what it renews at. A first-term discount that doubles at renewal is a real cost, just deferred.
• Whether the term is prepaid. Multi-year prepaid plans, which is how SSD Nodes sells, buy a much lower price per GB of RAM with money up front. The trade is that you cannot walk away next month, so match the term to how sure you are.
• What a snapshot costs per month, and what a restore costs in money and in minutes.
• Whether overage is billed or throttled.
• Whether IPv6 is routed properly or is a single address bolted on.
• Whether there is an API with a maintained Terraform provider, if you intend to rebuild from code rather than by hand.
• How support is reached, and the published response target for a server that is down rather than for a sales question.

Pick on the axis that dominates your own bill. If that axis is memory, the price per GB of RAM settles it. If it is outbound traffic, the included transfer settles it. If it is your own time, the managed platform settles it, and DigitalOcean's is the strongest of the four compared here.

FAQ

Is Hetzner always cheaper than DigitalOcean?

For a plain virtual machine, it is much cheaper per GB of RAM: about $1.62 against $6.00 on entry shared plans as of 5 August 2026. The comparison changes once managed services enter it. Hetzner sells servers and networking, so a managed database or a push-to-deploy platform has to come from you or from a third party, and those hours have a price. Hetzner also raised cloud prices during 2026, so check the current euro figure rather than trusting an older article.

Which DigitalOcean alternative should I pick if I need a managed database?

Vultr and Akamai both sell managed databases, so they are the closest substitutes if the managed database is the reason you are on DigitalOcean at all. The low-cost European hosts generally do not sell one, which means running PostgreSQL or MySQL yourself, including replication and a tested failover. That is a real job. Price it against the $15.15 a month that a managed 1 GiB instance costs before you decide the cheaper server saved you anything.

How do I move a live site to a new provider without downtime?

Lower the DNS TTL to 300 seconds at least 48 hours before the move, because resolvers keep serving the old IP for as long as the previous TTL told them to. Build and test the new host while the old one still serves traffic, using a /etc/hosts override on your own machine so nobody else sees it. Then freeze writes for a few minutes, run the final rsync delta and the final database sync, switch the A and AAAA records, and leave the old server running for a week in case a resolver ignored the short TTL.

Does a cheaper VPS mean slower disks?

Not by itself. What matters is whether your virtual disk is local to the host or on a network storage cluster, and the panel rarely says. lsblk -o NAME,ROTA reports 0 for both, because both are non-rotational. Measure instead: run fio with --iodepth=1 --bs=4k --direct=1 and read the 99th percentile completion latency. A network volume adds a datacentre network round trip to every read, so its latency floor sits higher than local NVMe even when deep-queue throughput looks similar.

Will my email still be delivered from the new server?

Often not, at first. A new IP address has no sending history, so receivers treat mail from it as suspicious and it lands in spam or is rejected outright. SPF and DKIM records also point at the old host until you update them. Send application mail through a relay or an email service that already has reputation, and update the DNS records for mail before the cutover rather than after.