Why We Built JengaStack — The Engineering Behind Kenya's First Managed Odoo Platform

Most ERP hosting providers just spin up a container and call it a day. We couldn't accept that. Here's why we built our own platform from scratch — and why that matters for Kenyan businesses.

Share
Why We Built JengaStack — The Engineering Behind Kenya's First Managed Odoo Platform

Why We Built JengaStack

Most ERP hosting providers just spin up a container and call it a day. We couldn’t accept that.

Here’s why we built our own platform from scratch — and why that matters for Kenyan businesses.

The Problem with “Managed Odoo” in Kenya

If you search for “Odoo hosting Kenya” in 2026, you’ll find two categories:

  1. International cloud hosts — They run Odoo on shared servers. You get a login URL and nothing else. No local payment integration. No KRA compliance. No support for M-Pesa. Good luck.
  2. Local resellers — They install Odoo on a DigitalOcean droplet, configure basic email, and hand you the admin password. Need a backup? They’ll get to it. Need eTIMS? That’s extra. Need M-Pesa? “We’re working on it.”

Neither solution treats Odoo as a platform. They treat it as a container.

That gap is why JengaStack exists.

What We Actually Did

We built a control plane that sits between the customer and the infrastructure. Every Odoo instance we deploy goes through this pipeline:

graph LR
    A[Customer Pays] --> B[Django Control Plane]
    B --> C[Komodo Orchestrator]
    C --> D[Docker Compose Stack]
    D --> E[Odoo Container]
    D --> F[PostgreSQL Container]
    E --> G[KRA eTIMS]
    E --> H[M-Pesa Daraja API]

When a customer signs up and pays, here’s what happens automatically:

  1. A unique subdomain is provisioned
  2. A Docker Compose stack is created with CPU/RAM limits based on their plan
  3. Traefik automatically issues a Let’s Encrypt certificate via Cloudflare DNS-01
  4. The Odoo container starts with pre-installed compliance modules
  5. The database is created, SSO is configured, and admin access is set up
  6. A health check runs — and only then does the customer get their “ready” email

Step 6 is important. We don’t send the email until the URL returns HTTP 200. We learned that the hard way.

Why Docker Compose (Not Kubernetes)

This will upset some people, but: we chose Docker Compose over Kubernetes.

Not because K8s isn’t powerful, but because it’s the wrong tool for this job.

We run about 50–100 tenant Odoo instances. At that scale, the overhead of operating a Kubernetes cluster — the control plane, the RBAC, the service meshes, the CNI plugins — doesn’t pay for itself. A Docker Compose stack per tenant gives us:

  • Predictable resource isolation (cgroups via Compose)
  • Simple networking (one stack, one network)
  • Easy debugging (docker logs, docker exec)
  • Zero control-plane costs
  • Single-host deployments

When we need to scale to multiple hosts, Komodo handles the orchestration. It’s the right abstraction for our scale.

Our Stack

Layer Technology Why
Edge Proxy Traefik v3 Automatic Let’s Encrypt, Docker service discovery
API Server Django + HTMX Rapid development, battle-tested, great admin UI
Task Queue Celery Reliable async job processing with retries
Database PostgreSQL 18 ACID compliance, pg_dump backups
Cache/Broker Redis 8 Celery broker, rate limiting, session cache
Orchestration Komodo Docker Compose manager with web UI
Monitoring Prometheus + Grafana + Loki Full observability stack
Uptime Uptime Kuma External HTTP monitoring per instance

What Makes It “Kenyan”

Most Odoo hosting platforms are built for global audiences. JengaStack is built for Kenya specifically:

  • KRA eTIMS — Every instance comes with pre-installed jenga_etims module that communicates with KRA’s API for real-time invoice signing
  • M-Pesa — Native STK Push integration via Safaricom’s Daraja API
  • Pricing in KES — No USD conversion friction
  • Local support — WhatsApp and email support in Kenyan business hours
  • Data residency — East African data centers, compliant with Kenya Data Protection Act

The Result

We’ve gone from “it works” to “it survives.”

Every instance is:

  • Automatically backed up (daily, off-site)
  • Monitored (response time, uptime, error rates)
  • Isolated (no cross-tenant access)
  • Self-healing (containers restart on failure)
  • Notified (we get Telegram alerts if something breaks — once every 6 hours, not every 10 minutes)

This is the infrastructure we wish existed when we started building for Kenyan businesses. So we built it.


Coming up next: How we build and deploy a multi-tenant Odoo platform step by step.