DigitalOcean runs data centers in a dozen or so metropolitan regions, identified by three-letter codes with a number: NYC1 to NYC3 and SFO2 to SFO3 in the United States, TOR1, ATL1 and the newer SYD1, LON1, AMS3, FRA1, SGP1 and BLR1 elsewhere. The region a resource is created in determines the latency your users see, the laws that apply to the data, and which products are available, because not every managed service exists in every region. It also determines almost nothing you can change later without moving the resource, which is why the right time to think about it is before the first Droplet, not after the database has a year of data in it.
Region lists go stale, so this post names the regions as they stand and spends its time on the decision, which does not. The mechanics of choosing well are the same on every provider: latency to the users who matter, residency rules that name a jurisdiction, and a check that the services you need exist where you plan to put them.
Table of contents
- The regions as they stand
- Latency: the users, not the office
- Residency and compliance: when the region is not a preference
- Product availability differs by region
- Why the choice is sticky
- A decision in four steps
- How this fits the rest of the stack
- FAQ
The regions as they stand
Grouped by continent, with the codes you will see in the control panel and the API.
- North America: New York (NYC1, NYC2, NYC3), San Francisco (SFO2, SFO3), Toronto (TOR1), Atlanta (ATL1), and a newer facility in the eastern United States.
- Europe: Amsterdam (AMS3), London (LON1), Frankfurt (FRA1).
- Asia-Pacific: Singapore (SGP1), Bangalore (BLR1), Sydney (SYD1).
Two older facilities, AMS2 and SFO1, are closed to new resources. If an old account still has Droplets there, the provider’s guidance is to migrate them to AMS3 or SFO3, and the migration is a snapshot and a restore, which is the same procedure as any other region move. The authoritative list is the control panel’s region dropdown or doctl compute region list, both of which also show which regions are accepting new resources today.
doctl compute region list
# Slug Name Available
# nyc1 New York 1 true
# sfo3 San Francisco 3 true
# ams3 Amsterdam 3 true
# ...Latency: the users, not the office
The most common mistake is picking the region nearest the team. The region should be nearest the users, or nearest the largest group of them. A business in Manchester serving customers across Europe wants LON1 or AMS3 or FRA1, and the difference between those three is a handful of milliseconds. A business in Manchester serving customers in Southeast Asia wants SGP1, and the difference between SGP1 and LON1 for those users is a couple of hundred milliseconds on every request, which is the difference between a page that feels instant and one that feels remote.
Two things soften this. A CDN in front of static assets moves the bulk of the bytes to edge locations near every user regardless of origin region, so only the dynamic requests pay the distance. And for an application whose users are genuinely global, a single region is a compromise wherever it is; the honest options are to accept that or to run in two regions with the complexity that brings.
Measure rather than guess. Each region has a public speed-test endpoint, and a few ping or curl timings from the places your users actually are will settle the question in five minutes.
Residency and compliance: when the region is not a preference
For some data the region is chosen by a lawyer. European personal data under GDPR is most simply handled by keeping it in an EU region, which means AMS3 or FRA1; London is outside the EU and the adequacy arrangements are a topic of their own. Data subject to Indian localisation rules points at BLR1. Australian government and health data often needs to stay in Australia, which is SYD1. Canadian public-sector work tends to want TOR1.
The provider’s compliance certifications, SOC 2 and the like, apply across regions, so the region choice is about jurisdiction rather than about the audit status of a specific building. If a contract or a regulation names a country, the region is decided and everything else in this post is secondary.
Product availability differs by region
Droplets exist everywhere. Managed databases, Kubernetes, the container registry, object storage, load balancers, and the newer GPU and app-platform products each have their own list of supported regions, and the newest regions typically get the newest products last. Before committing to a region, check the specific products you plan to use, because discovering that the managed database engine you want is not offered in the region your Droplets are in means either a cross-region database connection, which is slow and metered, or a move.
Object storage in particular has a shorter region list than compute, and since it is often the destination for backups, a compute region with no nearby storage region means backups cross the ocean. That works; it is just slower and it costs bandwidth.
Why the choice is sticky
Region is not a setting on a resource; it is where the resource physically is. Moving a Droplet is a snapshot, a transfer of the snapshot to the new region, and a new Droplet from it, with a new IP address. Moving a managed database is a backup and a restore into a new cluster, with downtime for the cutover unless you set up replication first. Moving a Kubernetes cluster is a new cluster and a redeploy. Every one of those is a project with a maintenance window, and the volume of data multiplies the time.
Private networking makes it stickier. A VPC is per region. Resources in different regions talk over the public internet, encrypted if you arrange it, metered as bandwidth, and slower. A stack that is half in one region and half in another because someone picked the wrong dropdown once is a stack with a permanent tax on every database query.
The practical rule: decide the region for the project, write it down, and create every resource in it. Naming the region in the project name or in a tag makes the mistake visible in a list rather than in a latency graph.
A decision in four steps
- If a regulation or contract names a jurisdiction, pick the region in it and stop.
- Otherwise, find where the majority of users are and shortlist the one or two regions nearest them.
- Check that every product you intend to use is available in the shortlisted region, especially the managed database and object storage.
- Create everything in that region, put a CDN in front of static assets, and revisit only if the user base moves.
Most projects finish step one or two with a clear answer. The projects that get it wrong are the ones that skipped step three and found out at the moment they needed a managed database.
How this fits the rest of the stack
Region is one of the decisions that a platform can make simpler by making fewer of them necessary. A service on RunxBuild is deployed with its managed database on a private network beside it, so the cross-region tax described above does not arise by accident. The RunxBuild hosting calculator is the place to see what the service, the database and the bandwidth cost together, which is the comparison that matters once the region question is settled and the bill is the next one.
Useful related references:
- Digital Ocean Managed Hosting: What Managed Means, and Who Does What
- DigitalOcean App Platform: The PaaS-vs-VM Decision, Explained
- MCP Server Design for a Digital Goods Storefront
- Services on RunxBuild
FAQ
Where are DigitalOcean’s data centers?
New York, San Francisco, Toronto, Atlanta and a newer eastern US site in North America; Amsterdam, London and Frankfurt in Europe; Singapore, Bangalore and Sydney in Asia-Pacific. Codes are three letters plus a number, such as NYC3, FRA1 or SGP1. The control panel and doctl show the current list and which regions accept new resources.
Which DigitalOcean region should I choose?
The one nearest your users, not your team, unless a regulation names a jurisdiction, in which case that decides it. Then confirm the products you need, especially managed databases and object storage, are available in that region before creating anything.
Can I move a Droplet to a different region?
Yes, by taking a snapshot, transferring it to the new region, and creating a new Droplet from it. The new Droplet has a new IP address. Managed databases move by backup and restore into a new cluster, with downtime unless replication is set up first.
Are all DigitalOcean products available in every region?
No. Droplets are everywhere, but managed databases, Kubernetes, object storage, load balancers and newer products each have their own supported-region list, and new regions receive new products last. Check availability for each product before choosing a region.
Does the region affect GDPR compliance?
It affects where the data physically resides, which is the simplest way to satisfy EU residency expectations. Amsterdam and Frankfurt are inside the EU; London is not. Compliance certifications apply across regions, so the region choice is about jurisdiction rather than audit status.