In the previous article, we introduced the DIGITAfrica blueprint approach modular, open-source reference architectures built from reusable services that can be combined and adapted to different research and education needs.

But a common technical foundation alone is not enough. Digital infrastructure in Africa must respond to a diverse range of resources, connectivity conditions, technical expertise, institutional requirements, and operational contexts.

This is why the DIGITAfrica framework has been developed around flexibility, scalability, and adaptation to local needs.

Developing a framework for Africa

DIGITAfrica blueprints are designed for a set of constraints and objectives that differ significantly from those typically assumed by research infrastructure initiatives in Europe and North America. These contextual differences are not peripheral considerations: they directly influence architectural decisions, technology selection, deployment models, and operational practices.

First, resource constraints are real and heterogeneous. Deployments may range from well-resourced environments connected to high-speed National Research and Education Network (NREN) infrastructure to highly constrained sites where power is unreliable and connectivity depends on intermittent, lossy links.

Architectures must therefore tolerate substantial variation in compute, storage, power, and network availability rather than assuming a continuously connected, resource-rich environment.

Second, operational expertise varies across sites. Not all deployments can rely on large teams with highly specialized infrastructure expertise. Technologies must consequently be open source, well documented, automatable, and maintainable with a reasonable level of operational expertise. Deployment and lifecycle management should minimize the amount of site-specific knowledge required to operate the infrastructure.

Third, the dual role of research and education is central. The same infrastructure must support both advanced research workloads and educational use cases. This includes environments for experimentation and scientific computing, as well as teaching platforms that can serve students operating under constrained bandwidth and limited access to local computing resources.

Fourth, sustainability is a core technical requirement. Infrastructure must account for energy availability and consumption from the outset. Energy efficiency is therefore not simply an optimization applied after deployment; it is an architectural constraint.

Finally, data sovereignty and privacy are paramount, particularly for digital health and agriculture.

A multi-tier deployment model

The same diversity that motivates a composable architecture also led to a multi-tier deployment model. A single deployment profile would either be too demanding for constrained environments or too limited for larger institutions.

The tiered model instead provides a progression from small, resource-constrained installations to a federated, continent-wide infrastructure.

DIGITAfrica defines five tiers, each capable of supporting the same underlying blueprints but differing in scale, available capabilities, degree of coordination, operational complexity, and cost:

The tiers should not be understood as five fundamentally different architectures. Rather, they represent different scales and operational contexts for deploying the same composable building blocks.

A central design principle is seamless scalability. Technologies, interfaces, and operational practices should remain sufficiently compatible across tiers so that experience and investment at one level can be carried forward to the next.

Partners can select the tier or combination of tiers that matches their available resources, technical skills, connectivity, institutional requirements, and needs and objectives.

The resulting framework combines two forms of flexibility. Composability allows partners to determine which services they need, while tiering allows them to determine at what scale and under what operational constraints those services should be deployed.

Testing the approach through practical deployments

The framework described above was not developed through architectural reasoning alone. The DIGITAfrica framework has been developed iteratively through the implementation and evaluation of running prototypes, in close collaboration with all project partners and users.

This hands-on process allowed us to validate assumptions against real deployment constraints, identify common requirements, and progressively converge on a shared set of needs and technologies.

Rather than attempting to implement every possible use case or support every combination of requirements from the outset, we focused on identifying the common ground across partners. This process ultimately led to the two major blueprints introduced in the previous article: the Edge-AI Blueprint and the Heterogeneous Networking Blueprint.

The iterative prototyping and testing process also allowed us to converge on a technology stack that provides a practical balance between flexibility, operational simplicity, and scalability.

Three technology choices

1. First, Ansible combined with GitOps provides the right balance for infrastructure automation.

Combined together, Ansible and GitOps offer reproducible and auditable mechanisms for managing configuration and infrastructure changes, with a low learning curve and without requiring the operational complexity or specialized expertise associated with more elaborate infrastructure-as-code platforms.

2. Second, resource management based on Docker Compose or Kubernetes through K3s provides a natural progression in resource management.

The objective was to avoid forcing small deployments to adopt the operational complexity of a full Kubernetes stack while retaining a clear path toward larger-scale orchestration.

Docker Compose is well suited to smaller, resource-constrained sites where a lightweight container runtime and simple service orchestration are sufficient. As requirements grow, the same containerized workloads can be deployed through K3s, providing Kubernetes-compatible orchestration with a comparatively small operational footprint.

K3s therefore provides a natural intermediate step toward a full Kubernetes deployment if scale, workload diversity, or federation eventually requires it.

This progression aligns naturally with the multi-tier architecture: Docker Compose can support smaller deployments in lower tiers, while K3s can provide orchestration at larger sites in middle tiers without requiring a completely different application model.

3. Third, Jupyter notebooks and JupyterHub provide the primary interface for accessing and deploying experiments and workloads.

This choice is driven as much by usability as by technical capability. A notebook-based environment provides an interface that can be learned quickly by any user, avoiding the steeper operational barrier.

It is also particularly well suited to education: teachers can distribute, demonstrate, and interactively follow practical exercises, while students can interact with computational resources without needing to manage the underlying infrastructure themselves, directly from their web browser.

At the same time, JupyterHub abstracts the execution environment and can therefore operate over different infrastructure backends.

Learning through hands-on testing

These choices have also been driven and validated by real users through hands-on training sessions from the early stages of the project.

In April 2025 in Cape Town, an initial 5G blueprint deployment highlighted the need for a simple yet powerful user interface.

In March 2026 in Nairobi, testing both blueprints confirmed the suitability of notebook-based workflows.

Further hands-on sessions in Tunis in April 2026 emphasized the importance of clear, multilingual documentation, while a broader Heterogeneous Networking session in Hanoi in July 2026 highlighted the need for robust distributed authentication and identity management across geographically distributed users.

In total, the hands-on activities have reached more than 100 different users around Africa, with users ranging from bachelor students to senior researchers and professors, providing a broad spectrum of potential user perspectives.

From blueprints to practical deployments

The Edge-AI Blueprint is implemented as a composition of these technologies. At Tier 0, single-user JupyterHub is deployed on a single node using either Docker or single-node K3s. At higher tiers, multi-node K3s clusters host multi-user JupyterHub.

The infrastructure is then specialized for Edge-AI through MLflow for end-to-end machine-learning lifecycle management and Grafana for workload and infrastructure observability.

The Heterogeneous Networking Blueprint builds on the same underlying infrastructure, but is specialized for networking experiments. K3s is configured to provide hardware passthrough, enabling direct access to devices such as USB-connected programmable radios, and Docker-in-Docker is used to allow experiments to run multiple isolated containers within their notebook environment.

A 5G core and RAN, based on OpenAirInterface, are deployed alongside this infrastructure, providing users with a fully functional 5G network sandbox for experimentation.

Looking ahead

DIGITAfrica demonstrates that a common infrastructure can support diverse African contexts through composable blueprints and a scalable multi-tier architecture. The two initial blueprints validate this approach across distinct domains while sharing the same underlying technology stack.

The next step is to integrate new verticals by specializing the blueprints to address agricultural and rural e-health use cases, building on the common infrastructure already established.

Time to test! https://gitlab.inria.fr/digitafrica/blueprints

Authors: Damien Saucez (Inria Centre at Université Côte d’Azur) and the DIGITAfrica WP2 team