DEV Community: Pritt Patrick

XRadius: Building a Modern ISP & Wi-Fi Hotspot Billing Platform with Go, MikroTik, M-Pesa and WebSockets

Pritt Patrick — Wed, 12 Aug 2026 06:40:52 +0000

Running an ISP or public Wi-Fi hotspot in Kenya is more than putting up a router and connecting customers.

You need to manage customers, internet packages, payments, network access, routers, sessions, revenue, staff, and support — often across several systems.

That is the problem I wanted to solve with XRadius.

XRadius is an ISP and Wi-Fi hotspot billing platform designed for internet service providers and hotspot operators. The goal is simple:

Make it easier to sell internet, collect payments, manage networks, and give customers a seamless connection experience.

The problem

Imagine a customer arrives at a Wi-Fi hotspot and wants:

10 Mbps — 1 hour — KES 20

The traditional workflow might look something like this:

Customer selects a package.
They enter their phone number.
They initiate an M-Pesa payment.
They wait.
The operator checks whether payment arrived.
Someone activates the customer's internet access.
The customer refreshes the page and hopes it worked.

That experience can be frustrating for both the customer and the operator.

I wanted XRadius to make this process automatic.

What is XRadius?

XRadius is being built as a multi-tenant platform for ISP and Wi-Fi hotspot businesses.

At a high level:

                    ┌─────────────────────┐
                    │      XRadius        │
                    │   ISP Platform      │
                    └──────────┬──────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
          ▼                    ▼                    ▼
     Customers             Payments             Network
          │                    │                    │
          ▼                    ▼                    ▼
    Captive Portal          M-Pesa             MikroTik
                              │                    │
                              ▼                    ▼
                         Transactions          Internet

The platform brings these pieces together instead of requiring the operator to manage them independently.

Why Go?

The backend is being built with Go.

Go is particularly attractive for this kind of system because XRadius needs to handle several concurrent activities:

API requests
Payment callbacks
Customer sessions
Router communication
Background jobs
Notifications
WebSocket connections
Dashboard updates

Go's lightweight concurrency model makes it a good fit for an application that needs to manage many simultaneous connections and background operations.

The backend follows a modular architecture with components for authentication, customers, billing, payments, networking, dashboards, and notifications.

The technology stack

The current architecture includes technologies such as:

Go — backend/API
PostgreSQL — primary database
Redis — caching, queues and real-time state
MikroTik RouterOS API — network provisioning and control
M-Pesa Daraja API — payments
JWT — authentication
WebSockets — real-time communication
Docker — deployment and service orchestration

The system is designed so that additional payment providers and networking integrations can be added later.

The captive portal

One of the most important parts of XRadius is the customer-facing captive portal.

A customer should not need to understand anything about RADIUS, MikroTik, APIs, or payment callbacks.

They should simply see something like:

EXTREME SOLUTIONS

Plug In. Connect Up. Go Extreme.

Choose your package

10 Mbps
1 Hour
KES 20

[ Buy Now ]

After selecting the package, the customer enters their phone number and initiates payment.

The complicated infrastructure should happen behind the scenes.

M-Pesa + WebSockets

One of the features I'm particularly interested in is combining M-Pesa payment processing with WebSockets.

The flow looks like this:

Customer
   │
   │ Select package
   ▼
Captive Portal
   │
   │ HTTP request
   ▼
XRadius API
   │
   │ Initiate payment
   ▼
M-Pesa
   │
   │ Payment callback
   ▼
XRadius Backend
   │
   ├── Verify transaction
   ├── Update PostgreSQL
   ├── Update Redis
   └── Provision internet
            │
            ▼
        MikroTik
            │
            ▼
       Internet Access
            │
            ▼
        WebSocket
            │
            ▼
         Customer

Instead of making the customer repeatedly refresh the page, the frontend can maintain a WebSocket connection.

When the payment is confirmed, XRadius can immediately notify the customer:

Payment successful! Connecting you to the internet...

Then the customer can be redirected into their active internet session.

This makes the payment-to-connect experience feel much more like a modern application.

Real-time admin dashboard

WebSockets are not only useful for customers.

They can also make the administrator dashboard much more dynamic.

For example, an operator could see:

ONLINE USERS       127
ACTIVE PACKAGES     84
TODAY'S REVENUE     KES 18,450
ACTIVE ROUTERS       6
PAYMENTS TODAY      312

Instead of refreshing the dashboard every few seconds, important changes can be pushed to the browser in real time.

For example:

M-Pesa Payment Received
        ↓
Transaction Created
        ↓
Database Updated
        ↓
WebSocket Event
        ↓
Admin Dashboard

The revenue counter can update immediately.

The online-user count can change immediately.

A router going offline can trigger an alert immediately.

MikroTik integration

The network layer is where XRadius becomes more than a normal billing application.

The platform is designed to communicate with MikroTik routers through the RouterOS API.

This allows the billing system to interact with the actual network infrastructure.

For example:

Customer purchases package
          ↓
Payment confirmed
          ↓
XRadius determines package
          ↓
Bandwidth rules applied
          ↓
MikroTik receives configuration
          ↓
Customer gets internet access

This also opens the door to features such as:

Multiple router management
Online user monitoring
Bandwidth control
Session management
Hotspot provisioning
Router health monitoring
Automatic user disconnection after expiry

The goal is to move from manually managing routers to managing the network from one platform.

Bandwidth control

An internet package is not simply a price and duration.

It can also define network behavior.

For example:

Package	Speed	Duration	Price
Starter	5 Mbps	1 hour	KES 10
Standard	10 Mbps	3 hours	KES 25
Premium	20 Mbps	24 hours	KES 50

XRadius can use the package configuration to determine the appropriate bandwidth policy when provisioning a customer.

This creates a direct relationship between:

Payment → Package → Network Policy → Internet Access

Redis

Redis plays an important supporting role in the architecture.

Some information does not need to be repeatedly retrieved from PostgreSQL.

Redis can help with:

Caching
Session state
Temporary payment state
WebSocket-related state
Background job queues
Rate limiting
Short-lived data

For example, payment processing can involve several asynchronous steps.

Redis can help coordinate temporary state while PostgreSQL remains the source of truth for persistent financial records.

PostgreSQL

PostgreSQL acts as the primary persistent data store.

The domain model includes concepts such as:

Customers
Internet packages
Invoices
Payments
Routers
Hotspots
Transactions
Users
Businesses

This provides the foundation for reporting, billing history, customer management and auditing.

Multi-tenant architecture

One of the important goals of XRadius is to support multiple ISP and hotspot businesses from the same platform.

The basic concept is:

                    XRadius
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
    Business A     Business B     Business C
        │              │              │
     Routers         Routers         Routers
     Customers       Customers       Customers
     Payments        Payments        Payments

Each business should be able to manage its own:

Customers
Packages
Routers
Payment accounts
Revenue
Staff
Network infrastructure

This creates the possibility of XRadius becoming a platform rather than simply software installed on one router.

Security matters

Because XRadius handles payments, customer information and network infrastructure, security cannot be an afterthought.

The architecture therefore needs to consider:

Secure password storage
JWT security
Role-based access control
API authentication
Rate limiting
Input validation
Payment verification
Secure secrets management
Audit logging
Database security
Router credential protection
WebSocket authentication
Secure Docker configuration
HTTPS/TLS

A compromised billing system could potentially become a compromised network.

That makes security one of the most important parts of the project.

The business model

The platform is being designed around a SaaS model for Kenyan ISP and hotspot operators.

An operator could sign up, configure their business, connect their payment account, configure internet packages and connect their MikroTik routers.

From there, they can manage their operation from the XRadius dashboard.

The broader vision is:

One platform for running an ISP or Wi-Fi hotspot business.

What makes the project interesting?

For me, the interesting part of XRadius is that it sits at the intersection of several technologies.

It combines:

Fintech

M-Pesa and payment processing.

Networking

MikroTik, bandwidth management, hotspots and sessions.

Backend engineering

Go, PostgreSQL, Redis and APIs.

Real-time systems

WebSockets and live dashboards.

SaaS

Multi-business architecture and subscription management.

These aren't isolated components.

They have to work together.

A payment needs to eventually become network access.

A network session needs to become billing information.

A customer action needs to trigger backend events.

A router problem needs to become an administrator notification.

That integration is where the real engineering challenge lies.

Where XRadius is heading

There are several areas I want to continue exploring:

Real-time M-Pesa payment status
Real-time admin dashboards
Multi-router management
Better bandwidth management
Automated router provisioning
Advanced revenue analytics
Customer notifications
Network health monitoring
Mobile applications
More payment providers
AI-assisted ISP analytics
Automated anomaly detection

The long-term goal isn't just to build another billing dashboard.

It's to build infrastructure that helps small and growing internet businesses operate more efficiently.

Final thoughts

Building XRadius has been an interesting journey because it forces software engineering and networking to meet in the real world.

A customer doesn't care that a payment callback went through an API.

They care that they paid and got internet.

An ISP operator doesn't care that a WebSocket event was emitted.

They care that their dashboard accurately shows who is online and how much they have earned.

That's the standard I'm aiming for with XRadius:

Hide the complexity. Automate the workflow. Make internet businesses easier to run.

And ultimately:

XRadius — Connect. Bill. Manage. Grow.

If you're interested in ISP infrastructure, MikroTik, RADIUS, M-Pesa integrations, Go, real-time systems, or building technology for African connectivity businesses, this is a project I'll be documenting as it evolves.

Building JONAM: Using Copernicus Earth Observation Data to Help Restore Lake Victoria's Fisheries

Pritt Patrick — Wed, 12 Aug 2026 06:22:47 +0000

"What if satellite data could help protect the livelihoods of millions who depend on Africa's largest lake?"

Last weekend, our team JONAM had the privilege of participating in the Kijani Space Hackathon, where we proudly secured 3rd place while tackling Challenge 2: Sustainable Fisheries & Blue Economy.

Rather than building another dashboard, we wanted to solve a real problem affecting millions of people around Lake Victoria: declining fish stocks caused by worsening water quality.

The Problem

Lake Victoria supports millions of people through fishing, transportation, agriculture, and tourism. However, over the years the lake has experienced:

Increasing water pollution
Poor water quality
Frequent algal blooms
Reduced fish breeding habitats
Declining fish populations

For fishing communities, these are not just environmental issues—they directly affect livelihoods, food security, and local economies.

Our question became:

Can Earth observation data help communities understand where water conditions are becoming unsuitable for fish before the problem becomes critical?

Our Solution: JONAM

JONAM is an AI-powered web application that combines satellite-derived environmental data with machine learning to monitor water quality and provide insights into conditions that may contribute to declining fish stocks.

Instead of relying solely on manual sampling—which is expensive and only covers small areas—our platform continuously analyses satellite observations covering the entire lake.

Why Copernicus?

To build JONAM, we integrated the KijaniBox API, which provides access to environmental datasets from the Copernicus Programme.

Copernicus is the European Union's Earth observation programme. It uses a constellation of Sentinel satellites together with in-situ observations to monitor Earth's atmosphere, land, and oceans.

For our project, we focused specifically on live water telemetry variables available through the KijaniBox platform.

1. Water Temperature

Satellites measure the thermal radiation emitted from the water surface to estimate temperature.

Temperature influences:

Fish metabolism
Oxygen availability
Fish breeding conditions

Abnormally warm water can reduce dissolved oxygen and stress aquatic ecosystems.

2. Turbidity

Turbidity measures how cloudy the water is.

Using reflected sunlight captured by optical sensors, satellites estimate suspended sediments and particles within the water.

High turbidity often indicates:

Soil erosion
Runoff after rainfall
Pollution entering rivers and lakes

Excessive turbidity limits sunlight penetration and disrupts aquatic life.

3. Chlorophyll-a

Chlorophyll-a is estimated from the colour of the water observed by satellite sensors.

It acts as an indicator of phytoplankton concentration.

Moderate levels indicate healthy productivity.

Very high concentrations may indicate harmful algal blooms, which:

Reduce oxygen
Produce toxins
Kill fish
Signal nutrient pollution

4. Precipitation

Rainfall estimates are generated by combining satellite observations with weather models.

Heavy rainfall often transports:

Agricultural fertilisers
Industrial waste
Urban runoff
Sediments

into Lake Victoria, increasing pollution and nutrient loading.

5. Wind Speed

Wind speed is estimated using atmospheric observations and numerical weather prediction models.

Wind affects:

Water mixing
Oxygen distribution
Surface circulation
Dispersion of pollutants

Strong winds can either improve oxygenation or spread polluted water to previously unaffected areas.

From Data to Action

JONAM analyses these environmental variables together instead of looking at each independently.

By learning relationships between:

Temperature
Turbidity
Chlorophyll-a
Precipitation
Wind speed

our AI model identifies environmental conditions associated with deteriorating water quality and declining fish habitats.

The platform presents these insights through an intuitive dashboard, enabling users to monitor changing conditions across Lake Victoria.

Why This Matters

Traditional water quality monitoring often depends on field teams collecting samples from a handful of locations.

Satellite observations provide:

Consistent coverage
Frequent updates
Large-scale monitoring
Lower operational costs
Historical trends for comparison

This makes environmental intelligence more accessible to researchers, governments, conservation organisations, and eventually fishing communities themselves.

The Hackathon Experience

The Kijani Space Hackathon challenged us to think beyond technology and focus on measurable environmental impact.

Throughout the event, we transformed Earth observation data into practical insights that could contribute toward healthier aquatic ecosystems and more sustainable fisheries.

We're incredibly proud that JONAM earned 3rd place in Challenge 2, but the experience reinforced something even more valuable:

Satellite data becomes truly powerful when transformed into decisions that improve people's lives.

What's Next?

Our vision for JONAM extends beyond the hackathon.

Future improvements include:

Real-time water quality alerts
Fish habitat suitability predictions
Pollution hotspot identification
Decision support for fisheries management
Mobile access for lakeside communities
Integration with IoT sensors for ground validation

Final Thoughts

Hackathons often end when prizes are awarded.

For us, this is just the beginning.

Lake Victoria's challenges require continuous innovation, and by combining Earth observation, AI, and accessible environmental data through the KijaniBox API, we hope JONAM can become one small step toward more sustainable fisheries and cleaner waters.

If you're interested in Earth observation, environmental AI, or geospatial technologies, we'd love to connect and continue building solutions that make a real-world impact.

The future of conservation isn't just in collecting more data—it's in turning that data into timely, actionable intelligence.

Intro.

Pritt Patrick — Thu, 02 Jul 2026 11:59:56 +0000

Hello guys, I am a cloud DevOps apprentice at zone01 Kisumu. I am an automation enthusiast and I am ready to learn more about DevOps and Go.