Skip to content

VPS & dedicated

Choosing a datacenter city

Place your VPS in the city that best serves your users, checkout path, and mail reputation.

Updated Aug 29, 20263 min read11 reads
Choosing a datacenter city
How to choose a datacenter city for your VPS

Choosing a datacenter city means placing your VPS near the people and systems that matter most for your site. On our VPS plans you pick one city from New York, London, Frankfurt, Singapore, Tel Aviv, or Tokyo, and that guest stays in that location. Your choice affects latency for uncached pages, wp-admin work, payment checks, and mail paths tied to the server IP.

Match the city to your real traffic

Start with where your visitors, checkout flow, and payment processor sit most of the time. Staff can reach wp-admin over a VPN if needed, so their location is usually secondary. Some processors watch geo and latency patterns, and a sudden jump across continents can look risky to them. If you send mail from the VPS, reputation and rDNS follow that IP and its history, while the city still shapes the network path. Cached static files can sit on a CDN; uncached HTML, admin screens, and APIs still feel the distance to the origin.

Compliance is a separate decision. Choose the country that meets your requirements first, then pick the city inside that footprint. Do not choose Tokyo because a hotel test looked quick if your shop actually checks out for customers in the eastern United States.

What six cities means on a VPS

We offer six VPS locations so you can place a guest where it helps. One guest lives in one city. We do not anycast a single VPS across those sites. Two A records can give you DNS failover; that is not the same as anycast. Synthetic tests from one city only describe that city. A CDN time-to-first-byte figure is not your origin time-to-first-byte. If you need fast uncached HTML in both the EU and the US, plan two origins or honest HTML caching rather than one middle-ground server.

bash
curl -o /dev/null -s -w ‘dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}n’ https://example.com/

Run a check like that from a network near you and again from a network near your customers. A looking glass helps with routing questions; a second-city curl helps you judge the website. If only your own result looks good, you may have optimized for yourself instead of for them.

Commit to the city, then build around it

Pick the datacenter city, point DNS at the server, and cache what you can at the edge when your audience is global. Moving later means new IPs, fresh rDNS, updated allow-lists, and another pass on geo rules, so treat a move as a real migration. Write the city down when you order so firewall and processor settings match from day one. Anycast is a different design with its own routing and operations; it is not part of a standard VPS unless the product page says so.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Was this article helpful?

Be the first to rate this article.