Self-hosting in Nigeria: a beginner guide for teams
How a small Nigerian product team can move one critical system onto hosting it controls, without building a data centre.
Edition 1Revised Why editions?
Self-hosting means you can run at least one critical system on infrastructure you control. That might be a VPS you pay for, or a machine you can walk to. The point is simple. When a vendor, region, or invoice fails, you are not fully stuck.
This guide uses Nigeria as the worked example: power, uplink, and after-hours access. The same steps travel to other African markets. What changes is the local constraint set.
This is for small product teams taking a first step. It is not a plan to build your own data centre.
Why bother
Teams ask for this after a billing freeze, a dark region, or a sudden terms change. The teams that keep shipping already have a fallback path. In Nigeria that path has to respect power cuts, uplink quality, and who can answer the phone at 2 a.m.
For the decision language behind hosting choices, read more: data sovereignty in plain language. If you still need shared labels for the data itself, read more: how to classify product data.
Own one thing first
Do not move the whole stack in week one. Pick one critical service.
- The primary database
- Auth
- Object storage that holds irreversible customer data
Leave the rest on SaaS on purpose until you have a restore drill that works.
Write the constraints before you shop
Before you open a pricing page, write four answers down.
- Power. How long can you stay up on UPS or generator, and which workloads must survive a blackout.
- Uplink. Is office fibre good enough for backups and remote admin, or does the box need better peering.
- People. Who can SSH in after hours. If nobody can, keep the stack boring and documented.
- Money. A cheap VPS plus off-box backups often beats a half-finished on-prem lab.
A 30-day path
- List which systems, offline for 48 hours, stop the business.
- Move one of them onto hosting you can explain in one paragraph.
- Automate backups off-box, run a restore test, and write who has access.
- Keep a rollback plan so you can return to the last known good version without a scramble.
- Decide what stays SaaS on purpose, such as email or payments, and what you might own next.
You do not need Kubernetes on day one. Boring VMs, a database you can leave, and tested backups beat a cluster nobody can debug.
A Lagos (or other local) box helps, but location alone is not enough. You still need export paths, clear access rules, and runbooks that match how the team actually works.