Remote Device Management Platform for Telecom

About the Client

The client manages a large network of customer routers, and each one must be configured, updated, and kept consistent without sending a technician to the house.

The application they had for this had performance problems, and getting its client side onto devices was difficult. They set out to replace it with a new device management platform, designed to roll out across the whole subscriber network in stages.

Challenge

The brief came with three defining requirements:

Replace an application that was hard to deploy. Migrate the existing network management application to a modern stack, and make the on-device client simple to install and keep running.
Prove every change on real hardware. The platform had to be tested on physical routers in the client’s lab, on a network set up to stand in for a home, rather than only on emulators. Our team works on those devices remotely, over SSH.
Be ready for a staged rollout. The client plans to release the platform gradually — one building, then a neighborhood, a city, a province, and the country — collecting feedback and fixing issues between each step. The agent has to install cleanly and behave the same way at every stage.

Project Scope

The project runs in four phases:

Active development (complete).
Continued development.
Validation on physical routers in the client’s lab (in progress).
Staged rollout across the subscriber network (planned).

Solution we Delivered

We wrote both halves of the platform: the server and the agent that runs on each router.

A Server and an Agent on Every Router

The server is written in Python on FastAPI and talks to devices over REST and WebSockets, with Redis behind it. The agent on each router is written in Go and keeps its local state in SQLite. A dedicated discovery service lets a router find the server and register itself, so new devices need no manual configuration. Authentication and authorization on every connection prevent MAC address duplication, closing the route for one device to pose as another.

Testing on Physical Routers in the Client's Lab

Every change is tested remotely on physical routers in the client’s lab. A CI/CD pipeline builds, tests, and deploys each change, and a structured logging configuration records system activity, errors, and warnings, so that a fault on a device can be traced back to its cause.

From Console Commands to a Working Dashboard

The original brief was backend only: technicians would run everything from the console, so no front end was planned. As the platform grew, the client needed a screen. With no designer on the project, we built a dashboard in Streamlit, connected to the platform’s database — plain to look at and fully functional, so the client’s team can see and act on their devices without writing a command.

Client’s Results

1. Our Agent Running on Every Router in the Test Lab

The agent runs on all 15 routers in the client’s lab, configured and updated from the server. New routers register themselves through the discovery service, with no manual setup on the device.

2. A Dashboard in Place of Console Commands

The client’s team now sees and manages its devices on a screen, without running console commands. It went from an unplanned request to a working tool connected to live data, with no design phase in between.

3. The Same Team, Several Years On

The engineers who built the platform are still developing it, through a change of engagement model from a full build team to a fixed monthly allowance of hours. The client keeps the knowledge of how the system works, and why, inside the team that wrote it.

4. Ready for a Staged Rollout

The platform is running on physical routers in the client’s lab. The next step is the client’s: releasing it to subscribers in stages, starting with a single building.

Remote Device Management Platform for a Telecom Provider’s Router Network