Building and operating a public cloud from Kigali

Clarance Liberi · Strettch Cloud
Awesomity · 14 August 2026

Friday
22 February 2019

Official launch of Rwanda Coding Academy

The first RCA website

Presenting the website at the RCA launch, 2019 — presenting it · 22 feb 2019

After the presentations

“Your website is dry.”

Aime Milembe walks up. Offers feedback. Changes everything.

With Aime Milembe at the RCA launch, 2019 — kigali · 2019

awesomity.rw · 2019

I opened inspect element looking for proof it was a template

The console.log signature found on awesomity.rw

So we started a company

Stunnity Soft

Simply stunning creativity softwares.

Some of the things we tried

stuneventsfailed

stunlabfailed

stunparkfailedand the idea got copied

RCA website v2failed

Kuriousfailede-learning. A separate startup, outside Stunnity. Cedric and I worked on it together.

evolve.rw
and client sitesshipped

Then career mode

2020Signa: software for abunzi (MINIJUST)QA
21–22MINADEF · NISS: e-learning platformFull-stack and team leadwith Gustave, Blessing
22–23BP: fleet management platformSenior frontend engineer
23–24Pivot Access: traffic fines, driving examsFull-stack, team leadwith Gustave, Cedric
24–25RSSB: imisanzu and ishemaSoftware engineer
24–nowStrettch → Strettch Cloud

Gustave since Stunnity. Cedric since Kurious. Blessing since MINADEF. The founding team assembled itself over six years.

Then career mode.

Signa, QA, software for abunzi at MINIJUST.

MINADEF and NISS, e-learning platform. Full-stack and team lead.

BP, fleet management, senior frontend.

Pivot Access, traffic fines and driving exams. If you've ever paid a traffic fine in this country, you're welcome. (beat) Worked with Cedric again there.

RSSB, imisanzu and ishema. If you've ever checked your imisanzu, some of my energy is in that page loading.

Then Strettch. Then Strettch Cloud.

Notice who keeps showing up. Gustave I worked with at Stunnity, then MINADEF, then Pivot. Blessing at MINADEF. Cedric on Kurious, then Pivot again.

Nobody recruited this founding team. It assembled itself over six years, and we had already failed together before we ever built anything that worked.

The itch

We'd failed a lot.
We'd learned a lot.
Too much potential
to waste.

So we started Strettch, an agency to advise people through the mistakes we'd already made, and to find a product of our own while we did it.

Finding the idea

We landed on a problem we had all felt.

We talked through plenty of ideas and tried a few. They all failed. Then came one we recognised immediately, because we had felt it ourselves or knew people who had. So we pivoted and went all in.

If you build software for companies in Rwanda

You have exactly two hosting options.

The two buttons meme: pick servers here, or a platform that works

Option one

The global clouds

Your users are here. The servers are not.every request commutes to Europe and back
You pay in dollarsyour CFO hates it, your margins hate it more
The law increasingly wants certain data stored in Rwandaso now compliance is your problem

Option two

Local providers

Servers are here. Everything else is missing.expensive, slow, limited services

26,000 RWF / month · 1 vCPU vs $5 elsewhere

The operating model is a human beingyou email someone. you WhatsApp someone. you call someone to reboot a server.
No transparency when it breaksyou find out your VM is down from your customers

A cloud platform without the compromise.

Infrastructure as a service, built and operated from Kigali.

What you get from Strettch Cloud

Self-service. You operate your own cloud.no emails, no WhatsApp. about two minutes.
Servers in Rwanda.compliance is a checkbox, not a project
RWF, hourly.destroy a VM after an afternoon, pay for an afternoon
More services than any local provider
A team that tells you the truth when things break.

October 2025

We launched. Private beta.

266,099RWF

Our entire first month of revenue.

5,317,057RWF

June. 20×, nine months later, with 700+ users on the platform.

Live

cloud.strettch.com

Product architecture

Walk it: every team gets its own VLAN, so your network never touches another customer's. A metadata service hands each VM its identity at boot, AWS-style. An agent ships metrics before you've even SSH'd in. And the billing meter is honest to the hour.

This room has engineers. This is where they decide whether you're real. Don't rush it, don't over-explain it.

If someone asks about the metal: we started on a small cluster of Dell R630s, that was the beta. Gen 1 is five R7525s, AMD EPYC, 2TB of RAM each. Collapsed-spine network, SONiC switches, BGP with EVPN-VXLAN for tenant isolation, 50 gigabits per server. Storage replicated twice synchronously on SSD, plus a Ceph erasure-coded tier for backups. Built for 2,000 to 3,000 VMs with an N+1 host in reserve, and team VMs deliberately spread across hosts so one dead server never takes out one customer's whole product.

Lesson 1

Design like any component can fail.

We once believed a commercial datacenter cannot lose power. Two grid feeds, generators, batteries, UPS. Five layers. On 16 December it lost power anyway, and what hurt us was everything we had built assuming one component would hold.

I used to believe a commercial datacenter cannot lose power. On paper it can't, two grid feeds, generators, batteries, UPS. Five layers.

So we put our monitoring on VMs in that same datacenter. Worst case, one server dies and the other alerts us. What could go wrong. (deadpan, do not smile first)

16 December, five past midnight, both feeds fail. Power was back in forty minutes. We were down about seven hours.

The outage wasn't the problem. The control plane came back believing every VM was still running, so it restarted nothing. Alerting was dead too, same building, same blackout. A VPN route hijacked the control plane's routing on the way up. And we were all asleep.

Forty minutes of theirs became seven hours of ours. That difference is design.

Your smoke detector cannot sleep in the same bed as the fire.

Most quotable line in the talk. Slow down for it, then stop talking.

If asked what we changed: monitoring now lives in an independent zone, someone else's building. Don't volunteer it, the lesson is the point.

Lesson 2

Our clients buy trust.

Our customers don't host websites on us. They host their customers on us. They expect things to run smoothly, and everything we do here protects that.

Lesson 3

The infrastructure game never ends.

We thought each piece would be done once. Build the feature, ship it, move straight to the next one. Nothing here stays finished.

A new performance bottleneck
A global security incident, usually someone else's bug
An internet outage nobody warned us about
Hardware that fails, after warning us for weeks
A new requirement, from a customer or a regulator

When we started we thought this was an easy game. Build a feature, ship it, mark it done, move straight to the next one.

We were never planning to build Strettch Cloud and walk away to something else. We just assumed each piece would stay built.

The truth is the infrastructure game never ends. Nothing stays finished, and there is always something.

A performance bottleneck we had not hit before. A global security incident, usually someone else's bug, and suddenly we are checking every box in our fleet. An internet outage nobody warned us about. Hardware that dies. A new requirement from a customer or a regulator.

Two of ours, if you want the detail:

October 15th, a server whispered an ECC memory warning in the logs. We were not listening. November 26th it stopped whispering: uncorrectable ECC, kernel panic, purple screen, 16 VMs down for two hours. The hardware gave us six weeks' notice and we missed it. Hardware whispers before it screams.

And in June we gave a test VM a public IP with the password Test@123. Root login on, password auth on. Cracked in thirty-seven seconds. Not hours, seconds. It spent a day as a 2-gigabit DDoS cannon pointed at China before our flow monitoring caught it. Our own box, our own dumb password.

Every single one of these was a problem we did not predict a month earlier. And honestly, that is why we love it.

Our current limitations

What we don't have

No SLA yet. Compute uptime last quarter was 99.8%. But we won't sell you a promise until we can back it with automated failover. Today you get the number, not the contract.
No managed services. No managed databases. No Kubernetes. No object storage. No one-click backups.

What's coming next

Uptime guarantee, a real SLA
Dual-stack IPv6 on every VM
The 50-gig east-west fabric
Managed Kubernetes
Storage as a product: volumes and S3-compatible object storage
Backups: scheduled, and one click to restore

Same building, six years apart

Students visiting the MTN datacenter, 2019 — students on a tour

Assembling the Strettch Cloud servers in the same datacenter, 2025 — assembling our own

Thank you

cloud.strettch.com

claranceliberi@strettch.com

@claranceliberi on X and LinkedIn

Building and operating a public cloud from Kigali

“Your website is dry.”

Stunnity Soft

We'd failed a lot.We'd learned a lot.Too much potentialto waste.

We landed on a problem we had all felt.

You have exactly two hosting options.

The global clouds

Local providers

A cloud platform without the compromise.

cloud.strettch.com

Product architecture

Design like any component can fail.

Our clients buy trust.

The infrastructure game never ends.

What we don't have

What's coming next

We'd failed a lot.
We'd learned a lot.
Too much potential
to waste.