Zero-Trust Networking in Africa: How OpenZiti Solves Remote Connectivity

Kubo is a non-profit initiative by Afrodidact, built around a simple but ambitious idea: every child deserves access to digital literacy, regardless of where they grow up. At the heart of it is the Kubo server — a Raspberry Pi running a self-contained digital platform that brings school administration, educational content, and community computing to schools in deprived areas. The platform was developed and tested at The Swallow, Afrodidact's model school in The Gambia, where students and staff connect through a local offline network while critical data is backed up over a minimal mobile internet connection.

The core challenge with a device like this is that it has no public IP. The 4G dongle uses CGNAT, which means the Pi is effectively invisible to the outside world. The traditional workaround is to punch a hole through something — a reverse tunnel, a VPN, an exposed port somewhere. It works, but it's fragile, and every hole you open is a liability.

OpenZiti flips that model entirely. Instead of reaching in to the device, everything reaches out to a central controller. The Pi dials out, your laptop dials out, and the controller brokers the connection between them. The device never needs an inbound port. It stays dark to the public internet. The only thing that needs to be publicly reachable is the controller itself, which we run on a small VPS.

What sold me beyond the architecture were two things. The first was practical: DNS resolution on the client. With a traditional VPN, accessing a service on the Pi meant remembering which port mapped to what and keeping forwarding rules tidy. With OpenZiti, you define a service with a proper FQDN — kubo.theswallow.rpi on port 443 — and you just browse to it. It feels like the device is sitting on your local network. Because in a sense, it is.

The second was more structural: fine-grained access control baked into the fabric of the network. Services and policies let you define exactly who can reach what — not at the firewall level as an afterthought, but as a first-class concept. A sysadmin gets SSH. A developer gets their service endpoint. A benefactor gets a Grafana dashboard. Nobody gets anything they weren't explicitly handed.

The current setup in The Gambia looks like this: the OpenZiti controller and router run on the VPS. An OpenZiti router runs on the Pi itself. Sysadmins and developers run the Ziti tunneler on their own machines, enroll once, and get access to exactly what they need — nothing more. No shared credentials. No "just leave port 22 open for now." Access is defined explicitly, and everything else is dark.

The moment it clicked for the rest of the team was when I pulled up the school administration platform in my browser during a meeting. No SSH, no port-forwarding, no preamble — just a URL, and there it was. Jaws dropped. That reaction said more about the value of this setup than any architecture diagram could.

And that's just the beginning of what this foundation makes possible.

The school administration platform is currently only accessible on-site. There's no technical reason it has to stay that way. With the right service definitions and policies, teachers and headmasters could reach it securely from their phones — they'd need the Ziti tunneler installed and a one-time enrollment, but after that, access is seamless and can be revoked instantly from one place if a phone is lost or a staff member leaves.

We're also looking at exposing metrics to Prometheus and surfacing a Grafana dashboard for the benefactors who fund the project — uptime, usage, basic health. OpenZiti means they get access to exactly that dashboard, with no broader foothold in the network.

The pattern repeats cleanly every time: define the service, define the policy, enroll the identity. Each role sees only what it needs to see, and the boundaries are enforced by the network itself — not by trust, not by convention, and not by hoping nobody tries the wrong port.

Here's what I keep coming back to. This isn't exotic infrastructure. It runs on a thirty-dollar computer behind a consumer SIM card. OpenZiti is open source. The whole stack is manageable by a small team without deep networking expertise.

Which means the same model works anywhere the problem looks similar. An NGO managing soil sensors or inventory systems for farmers in a remote area. A clinic where healthcare workers need authenticated access to patient records without exposing sensitive data to the open internet. A refugee camp where staff turnover is high and the ability to revoke access instantly isn't a nice-to-have — it's critical.

The technology has quietly reached the point where "secure, maintainable remote access in difficult conditions" is a solvable problem. It just needs someone to sit down and solve it.

If that's a problem your organisation is facing, I'd be glad to help. Feel free to reach out through the contact form.