London. One region, done properly.

Why only London

Most of the UK's population, its internet exchanges and the transit networks that join them sit within a few hundred kilometres of London. Routing traffic from Glasgow, Cardiff, Belfast or Norwich to a server in London is a well-trodden path. Routing the same traffic to a server abroad adds distance, extra networks and extra hops, all for users who never left the country.

So we run one region and spend our attention on it. One set of hypervisors to keep patched. One network to watch. One image list to keep current. You get a smaller menu and a clearer answer to the question "where is my server?" The answer is always London.

If your audience is global, a single London region is still a reasonable origin for Europe-facing work, but be honest with yourself about the users far away. A CDN in front of a London origin helps static assets; it does not make a chatty API call from another continent fast.

Latency, from first principles

Light in optical fibre travels at roughly two-thirds of its speed in a vacuum, about 200 km per millisecond. A signal from Manchester to London covers roughly 260 km of straight line, and fibre routes are never straight. Double it for the round trip, add the time routers spend forwarding packets, and add whatever your access network costs you.

That last part dominates. On a decent fibre broadband line or a business circuit, typical round trips from most of Great Britain to London land somewhere between 5 and 20 ms. Mobile networks and congested Wi-Fi add more, sometimes a lot more. These are typical ranges for UK paths in general, not figures we have measured or guarantee for your connection.

Why it matters for developers:

• Chatty protocols multiply delay. A page that makes eight sequential API calls pays the round trip eight times. Shaving 30 ms per trip is a quarter of a second back.
• TLS handshakes cost round trips. TLS 1.3 needs one before the first byte of data; older setups need two. Short paths make cold connections cheap.
• Interactive work feels it. SSH sessions, remote editors, database consoles and CI log streaming are noticeably snappier when the server is near.

Measure it yourself

Don't take a number from a marketing page, including this one. Spin up a Spark for a month, or test against a server you already have, and measure from where your users actually are.

Round-trip time with ping:

ping -c 20 203.0.113.10
# look at the min/avg/max/mdev line at the end

Per-hop view with mtr, which combines ping and traceroute and shows where loss or delay appears:

# Debian/Ubuntu
sudo apt install mtr-tiny
# AlmaLinux/Rocky
sudo dnf install mtr

mtr --report --report-cycles 100 203.0.113.10

Read the last hop's average and loss first. Loss shown on a middle hop that disappears further along is usually a router deprioritising ICMP replies to itself, not real packet loss. The full method, including TCP-level timing with curl, is in our latency measurement guide.

The network, per server

Unmetered means we don't count gigabytes and bill you for them. It doesn't mean the port is shared with nobody or that every path on the internet will carry a full gigabit to your laptop. Throughput to a given user is set by the slowest link between you, which is usually their side.

Reverse DNS and your one IPv4

Each server gets a single dedicated IPv4 address, and you control its PTR record from the portal. Set it to a hostname that resolves forward to the same address. Mail servers check this; so do some monitoring tools and a few picky APIs. A matching forward and reverse pair is a five-minute job that saves a support ticket later.

dig +short -x 203.0.113.10      # reverse
dig +short app.example.co.uk    # forward, should return 203.0.113.10

Where your data lives

Your server's disks sit in London. Snapshots and backups you create through the portal are part of the same platform. That gives you a straightforward answer when a client, a procurement form or your own data protection notes ask where personal data is processed: on infrastructure in the United Kingdom.

The boundary is your server, though. If your application sends logs to a third-party service, pushes backups to object storage abroad or calls an external API with user data, those flows are yours to document. Our privacy notice covers what we process about you as a customer; your own notice covers your users.

What runs well here

A London region suits workloads where the people or systems talking to the server are in the UK:

• APIs and web backends for UK customers, see API backends.
• Self-hosted CI runners close to a UK team, see CI runners.
• Staging environments that mirror a UK production stack.
• Databases sitting next to the app servers that query them.

Pick a size on the pricing page. All six plans run in the same London region with the same network specification; they differ only in vCPU, memory and NVMe capacity.