Why We Moved Our Web Infrastructure to Cloudflare Workers
Infrastructure Cloudflare Edge Computing Performance Nigeria

Why We Moved Our Web Infrastructure to Cloudflare Workers

This website runs on Cloudflare Workers. Not Vercel, not Netlify, not Azure Static Web Apps — Cloudflare Workers. Here’s why.

The Problem with Origin Servers for African Audiences

When you deploy a website on a single-region cloud VM or even a CDN with a European or American origin, every request from a Nigerian user travels a significant distance. Lagos to a Frankfurt server is roughly 6,000km. Even at the speed of light through fibre, that’s latency. Add TLS handshakes, TCP slow start, and the reality that Nigerian ISPs route through multiple hops before reaching international cables, and you’re looking at 200–400ms just to establish a connection.

For a marketing website, this is the difference between a visitor staying and a visitor leaving.

Why Cloudflare Workers

Cloudflare operates points of presence in Lagos, Nairobi, Johannesburg, Cape Town, and Accra. When a user in Lagos loads alcingsstudio.com, their request hits the Lagos PoP. Code runs at the edge — milliseconds away, not continents away.

Workers also means: no cold starts (unlike Lambda or Azure Functions), V8 isolates instead of containers (faster startup, lower memory overhead), and the Cloudflare network absorbing DDoS automatically.

The Astro + Cloudflare Adapter

This site is built with Astro 6 using the @astrojs/cloudflare adapter. In hybrid mode, all pages pre-render to static HTML at build time. The only SSR route is /api/contact — the contact form handler. The rest is static HTML served from Cloudflare’s cache.

The result: pages are served from cache with no compute cost and sub-50ms response times from Lagos.

Tradeoffs We Accepted

No Node.js built-ins. Cloudflare Workers run on V8, not Node.js. Packages that use node:fs, node:crypto, or other Node built-ins fail. This was relevant for one package we considered — we replaced it with a fetch-based API call instead.

Workers KV for persistence. If we needed server-side state, we’d use Workers KV or D1 (Cloudflare’s SQLite at the edge). This is different from thinking in terms of a PostgreSQL connection pool.

No long-running processes. Workers have a CPU time limit. For this website, irrelevant — our SSR route does minimal computation. For compute-heavy tasks, you’d use a Durable Object or a separate backend.

The Deploy Workflow

pnpm build
npx wrangler deploy

That’s it. The build takes ~30 seconds. Deploy takes ~10 seconds. The site is live globally in under a minute. No staging environment to manage, no EC2 instance to patch, no certificate renewal to worry about.

For a small studio like Alcings, the operational simplicity of this setup is genuinely valuable. We’re engineers — we’d rather spend time building products than managing infrastructure.

Verdict

For a marketing website with a Nigerian-heavy audience: Cloudflare Workers is the right choice. Faster than any single-region deployment, cheaper than enterprise CDN setups, and deployable in 40 seconds. We recommend it to clients building public-facing web assets.

Obichukwu Onyeowuzoni

LinkedIn

20 years building enterprise systems across healthtech, fintech, and government. I write .NET, think in systems, and care deeply about software that works in the real world.

Full story →