Choosing a VPS Region When Your Users Are in Kenya

If your users are in Kenya and you are self-hosting business software, put the server in Frankfurt unless you have a specific reason not to. Measured round trips from Nairobi run about 125ms to Frankfurt, 51ms to Johannesburg, 64ms to Cape Town, and 6ms to Mombasa, and those four numbers decide almost everything about this choice. The rest of the decision is provider coverage, cost, and what the Kenya Data Protection Act actually requires, which is less than most people assume.

This post gives you the real numbers, the region maps for the providers you are most likely to use, a worked example, and a test procedure you can run in a week before committing.

Why region choice is mostly a latency decision

Every interaction with a self-hosted app costs at least one network round trip. Opening a page costs several: TCP handshake, TLS handshake, then the request itself, and often a chain of API calls behind it. A 125ms round trip means a fresh connection burns roughly 400 to 500ms before your server has answered anything, and every subsequent request carries that 125ms floor.

Nielsen Norman Group's usability research puts the perception thresholds at 0.1 seconds (feels instant), 1 second (noticed, but the user's train of thought survives), and 10 seconds (attention is gone) (Nielsen Norman Group). With a Frankfurt server and a healthy app, a Nairobi user on fibre lands in the "noticed but fine" band. With a US East server at roughly double the distance, the same app starts to feel sluggish, and a chat-heavy tool like a support inbox becomes annoying to use all day.

Region choice is also sticky. Migrating a server later means moving data, re-pointing DNS, and re-running backups. It is worth spending one week measuring before you commit.

The measured numbers from Nairobi

SEACOM, the submarine cable operator, publishes a live latency matrix measured between African and European points of presence. The Nairobi row is the most useful public dataset for this decision (SEACOM latency matrix):

• Mombasa: 6ms. The cable landing city. Nairobi's international traffic physically passes through here.
• Kampala: 9ms, Dar es Salaam: 12ms, Kigali: 19ms. East African neighbours are effectively local.
• Johannesburg: 51ms. The nearest hyperscaler hub.
• Cape Town: 64ms. Home of AWS's only African region.
• Marseille: 113ms. Where several submarine cables from Mombasa come ashore in Europe.
• Frankfurt: 125ms. Europe's biggest peering hub and the default home of European VPS providers.
• London (Slough): 127ms. Amsterdam: 132ms. Comparable to Frankfurt.

Three things to take from this. First, geography is not linear: Marseille is physically closer than Frankfurt, but the difference is only 12ms, because both sit at the end of the same cable system. Second, the jump from "Africa" to "Europe" is about 70 to 75ms; that is the real price of hosting in Europe. Third, anything beyond Europe (US East, Singapore, Mumbai) stacks another 100ms or more on top, which is why those regions are not serious candidates for a Kenyan user base.

Kenya's international bandwidth arrives on submarine cables including SEACOM, EASSy and TEAMS, all landing in Mombasa, and the Kenya Internet Exchange Point in Nairobi keeps domestic traffic domestic (Wikipedia: Telecommunications in Kenya). That is why the realistic shortlist is exactly three options: Europe (Frankfurt), South Africa (Johannesburg or Cape Town), or Kenya itself.

What each provider actually offers near Kenya

Provider marketing pages list dozens of regions, but for Kenya the map is thin.

European VPS providers

Hetzner's cloud runs in Falkenstein and Nuremberg (Germany), Helsinki, two US locations, and Singapore (Hetzner Cloud). For Kenya that means Germany, full stop. The upside is price: shared-vCPU cloud servers start at about EUR 6 per month excluding VAT, with 20 TB of traffic included and EUR 1 per TB beyond that in EU locations. That traffic allowance is generous enough that egress fees effectively disappear for a typical business stack.

DigitalOcean has 16 datacenters across 13 regions, and the nearest one to Kenya is FRA1 in Frankfurt; it has no region anywhere in Africa (DigitalOcean regional availability). Same conclusion: Frankfurt.

Hyperscalers

AWS opened its first and still only African region in Cape Town in 2020: af-south-1, with three Availability Zones (AWS launch announcement). Azure has South Africa North in Johannesburg, with three Availability Zones, and South Africa West in Cape Town, which is a restricted region reserved mainly for disaster recovery pairing (Azure regions list).

Neither AWS, Azure, nor Google Cloud has a region in Kenya. If your organisation standardises on a hyperscaler, Johannesburg or Cape Town is where you land, at 51 to 64ms from Nairobi. That halves the European latency, but you pay hyperscaler prices, and metered egress can exceed the VM cost for chatty applications.

Kenya itself

Colocation and local hosting exist: Africa Data Centres runs carrier-neutral facilities in Nairobi and hosts the Kenya Internet Exchange Point, which is where local ISPs hand traffic to each other (Africa Data Centres). A server racked there, or a VPS from a local provider peered at KIXP, delivers single-digit-millisecond latency to Nairobi users. The trade-offs are price per unit of capacity, fewer managed services, and resilience: you are concentrating your infrastructure in one power grid and one network ecosystem.

The shortlist, ranked

For a Kenyan business self-hosting tools like a CRM, a support inbox, scheduling, analytics, and email marketing:

• Default: Frankfurt. 125ms from Nairobi, the cheapest mature VPS market in the world, huge provider choice, GDPR-grade data protection, and traffic allowances that make billing predictable. This is where most self-hosted stacks for East African users should live.
• Hyperscaler shops: Johannesburg or Cape Town. If you are already on Azure or AWS, or need managed databases, private networking, and compliance paperwork from a big-three cloud, the South African regions halve the latency to Nairobi at a higher price.
• Latency-critical or data-sensitive workloads: Nairobi. Voice and video media servers, real-time collaboration, and anything where 125ms is a product problem belong in-country. So does infrastructure where a client contract or internal policy demands Kenyan soil.
• Nowhere else. US regions, Singapore, and India are all 100ms+ worse than Frankfurt for Nairobi users. There is no workload for a Kenyan audience that belongs there by default.

A worked example

A 25-person Nairobi professional services firm runs the standard open-source stack: Twenty for CRM, Chatwoot for support, Cal.com for scheduling, Plausible for analytics, and Listmonk for email. All five fit comfortably on one 4-vCPU VPS.

Hosted on Hetzner in Falkenstein, the server costs roughly EUR 8 to 16 per month depending on the plan, with 20 TB of traffic included, so the annual infrastructure bill is around EUR 100 to 200 plus backups. The full cost model for this stack, including storage and backup sizing, is in Self-Hosting Your Business Stack: Server Sizes and Real Costs. If you would rather not operate it yourself, the pricing page shows what managed operation costs.

The latency budget for a staff member opening the Chatwoot inbox from a Nairobi office on fibre:

• Fresh connection: TCP plus TLS handshake costs about 3 round trips, roughly 375ms.
• Each subsequent request: 125ms of network plus server processing, typically 20 to 80ms for a healthy app.
• Perceived result: the first page load takes a beat; every click after that responds in well under half a second. Staff stop noticing within a day.

Move the same server to a US East region and every one of those numbers roughly doubles. The app does not break; it just quietly taxes every interaction your team has with it, thousands of times a week. Move it to a Nairobi data centre and the numbers collapse to near zero, which matters for some workloads and is wasted money for this one.

Data residency and the Kenya DPA

The Kenya Data Protection Act came into force on 25 November 2019, and it regulates rather than prohibits cross-border transfer of personal data; the mechanics sit in the General Regulations 2021, which specifically cover transfers outside Kenya (DLA Piper: Kenya). The same regulations set registration duties: controllers and processors above 5 million KES turnover and more than 10 employees must register with the Data Commissioner, and sectors such as financial services and health administration must register regardless of size.

The practical reading for hosting decisions:

• Hosting in Frankfurt is legal for a Kenyan business, provided the transfer conditions are met and your documentation is in order.
• EU hosting is not a downgrade. Hetzner, for example, is GDPR-compliant and ISO 27001 certified, which satisfies the "appropriate safeguards" instinct most clients and auditors have.
• Some organisations still choose Kenyan soil. Regulated institutions, or contracts that promise in-country storage, override the latency math. The compliance side of that decision, including when self-hosting genuinely helps your DPA position, is covered in Kenya Data Protection Act Compliance and When Self-Hosting Helps.

If a vendor or advisor tells you the DPA forces all data to stay in Kenya, ask them to point at the section. The Act restricts and documents cross-border transfer; it does not ban it.

How to test before you commit

You can validate the choice in about a week for under EUR 20:

1. Spin up candidate servers. Rent the cheapest VPS in Frankfurt, and if you are hyperscaler-curious, a small VM in Cape Town or Johannesburg. One provider per candidate is enough.
2. Measure round trips from real Kenyan connections. From an office on Safaricom or Zuku fibre and from a phone on Safaricom 4G, run mtr -rwbz -c 100 <server-ip> and record the average and the worst-case latency. Test at peak hours (10:00 to 12:00 and 19:00 to 22:00), not just on Sunday morning.
3. Measure what the app will actually do. Time full HTTPS requests, not just pings: curl -o /dev/null -s -w "connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://<server>/. The TLS figure shows the handshake cost; TTFB shows the real floor for every page load.
4. Deploy one real service. Put the actual candidate app on each server, create a few users, and have three staff members use each for a day. Perceived performance beats synthetic numbers.
5. Decide on evidence, then burn the boats. Pick the winner, move DNS, and shut the losers down so nobody drifts onto them.

If you are comparing WhatsApp-heavy support setups specifically, the hosting and number-setup costs interact with this choice; see Chatwoot WhatsApp Business API Setup and Costs in Kenya for that side of the budget.

Common mistakes

• Accepting the provider's default region. Several VPS and PaaS providers default to US regions. A team in Nairobi that clicks through the defaults ends up on US East and never questions why the app feels heavy.
• Assuming "Africa region" automatically wins. Cape Town at 64ms does beat Frankfurt at 125ms on paper. But if you want a cheap EUR 6 VPS rather than a hyperscaler VM, the African option on that provider does not exist, and the latency saving rarely justifies the price jump for CRUD-style business apps.
• Pricing only the VM. Egress is metered separately on hyperscalers and included generously on European VPS providers. A support inbox serving file attachments all day can invert the expected cost ranking.
• Testing from office fibre only. Your users may be on 4G with its own 30 to 60ms of radio latency. A region that feels fine on fibre can feel broken on mobile.
• Putting latency-sensitive media in Europe. Voice and video media servers at 125ms produce noticeable call lag. Signalling can live in Frankfurt; the media path should be regional.
• Forgetting where the data goes at night. Backups and replicas should follow the same region logic, or your disaster recovery restores over a transcontinental link.

When Frankfurt is the wrong choice

Be honest about the exceptions:

• Real-time media. VoIP media servers, video bridges, and remote-desktop gateways want the shortest path available. Host those in Nairobi or Johannesburg.
• Branches-only systems. A SACCO or cooperative whose entire user base sits on Kenyan ISPs gets single-digit latency locally, and the European option buys them nothing except a cable-cut dependency.
• Contractual residency. If a client contract or a regulator expects in-country storage, that settles it. Meet the obligation first, then optimise.
• Hyperscaler lock-in, in a good way. If your team already runs everything on Azure, South Africa North is a better operational fit than introducing a second provider to save 70ms.

For everyone else, the boring answer is the right one.

Frequently asked questions

Is Frankfurt or Johannesburg better for hosting for Kenyan users? Johannesburg is closer (about 51ms versus 125ms from Nairobi on SEACOM's live measurements) but only the hyperscalers have regions there, at hyperscaler prices. Frankfurt offers far cheaper VPS options with generous traffic allowances. For typical business software, Frankfurt's price advantage outweighs the 74ms difference; for real-time media, Johannesburg wins.

Does Kenya's Data Protection Act require data to be stored in Kenya? No. The DPA 2019, in force since 25 November 2019, regulates cross-border transfers rather than banning them, with the mechanics in the General Regulations 2021. Many Kenyan organisations legally host in the EU; some choose local hosting for contractual or policy reasons.

How much does it cost to self-host a business stack for a Kenyan company? A 4-vCPU European VPS running a full stack (CRM, support inbox, scheduling, analytics, email) costs roughly EUR 8 to 16 per month, with 20 TB of traffic included at providers like Hetzner. Budget separately for backups and a monitoring layer.

Is there an AWS or Azure region in Kenya? No. AWS's only African region is Cape Town (af-south-1, three Availability Zones, opened 2020). Azure's are South Africa North in Johannesburg and a restricted region in Cape Town. Nairobi workloads on either hyperscaler land in South Africa.

Does a CDN fix the latency problem for self-hosted apps? Only for static assets. Images, CSS and JavaScript served from a CDN with a Nairobi or Johannesburg point of presence load fast, but every dynamic request still travels to your origin region. A CDN softens first-page-load pain; it does not change the responsiveness of the app itself.

What latency should I expect from Nairobi to Europe? On SEACOM's live matrix, Nairobi to Frankfurt averages about 125ms, Amsterdam 132ms, and Marseille 113ms. Your own measurements will vary by ISP and time of day, which is why the test procedure above matters more than any published number.

Where to go from here

Pick Frankfurt, spend one week proving it with your own measurements, and get on with the work the stack is supposed to support. If you would rather have the whole thing, servers, regions, updates, and backups, handled for you, we deploy and run exactly this stack as a managed open-source stack service, and the hosting-region question is one we answer with measurements from your own offices before we provision anything.