Why We Build Static Next.js Sites for Shared cPanel Hosting in Ethiopia
If you've priced out hosting for a client project in Ethiopia, you already know the pattern: cheap, reliable shared cPanel hosting is everywhere, but almost none of it gives you a Node.js server to run alongside it. That single fact shapes a lot of decisions we make on Ab Tech projects, especially anything built with a modern React-based framework like Next.js.
The problem with the "normal" Next.js setup
Most tutorials assume you'll deploy a Next.js app to a platform like Vercel, or to a server that can run next start continuously. Neither is realistic for a lot of our clients — churches, small businesses, and organizations that already pay for cPanel hosting through a local provider and don't want (or can't justify) a second hosting bill for a Node server, especially when the exchange rate makes anything priced in USD expensive.
Static export as the middle ground
The fix we've landed on for most client sites is Next.js's static export mode. It compiles the entire site down to plain HTML, CSS, and JS files — no server process required — which means it can be uploaded straight into a cPanel public_html folder like any other static site. You keep the developer experience of React, file-based routing, and component reuse, but the deployed output is something any shared host can serve.
The trade-off is that anything genuinely dynamic — authentication, a database, an admin panel — can't live inside the Next.js app itself anymore. That's where the second half of the stack comes in.
Firebase (or a small PHP API) fills the gap
For most projects, we wire the static export up to Firebase — Authentication for admin logins, and Firestore for anything that needs to be editable without redeploying the whole site: gallery images, event listings, sermon notes, a "books" catalog, or giving-page bank details. The public pages fetch this data client-side, so content editors can update things from an admin dashboard without ever touching code or a deployment pipeline.
On projects where Firebase isn't the right fit, we use a lightweight PHP API instead, sitting in an /api folder on the same cPanel account, talking to a MySQL database the host already provides. Either way, the pattern is the same: static frontend, dynamic backend bolted on separately.
What this means in practice
For a recent church website project, this setup let us ship a fully bilingual site with an admin-managed hero slideshow, a books section, event and sermon management, and a multi-bank giving page — all hosted for the same monthly fee the client was already paying for their old static HTML site. No server migration, no new hosting contract, and no dependency on a platform that bills in dollars.
It's not the setup we'd choose if budget and hosting constraints weren't a factor. But for the reality most of our clients are working within, it's the combination that actually ships.