Balady+ Mini-Apps Platform

The problem

The Balady+ Super App needs to host third-party mini-applications safely. Letting external teams ship code inside a government super-app is a sharp edge: one bad mini-app can leak citizen identity, exfiltrate data, or take the host down.

The architecture

A container-based mini-app runtime with a permission bridge that exposes only gated native APIs. Each mini-app is sandboxed at the container boundary; the bridge mediates every native capability the mini-app can call (camera, location, payment, identity). Bridge permissions are declared up front at submission time and re-validated on every call — with parameter checking, rate-limiting, and audit logging — so a mini-app can never quietly widen the surface it was approved for.

Every mini-app passes through a multi-stage CI/CD gate: each image is pulled and verified, scanned for vulnerabilities and malware, checked for compliance, run through automated and manual review, and only promoted to the runtime after an explicit approval sign-off — with post-deploy validation closing the loop. A failure at any gate halts promotion automatically; nothing reaches the runtime without passing every check, and manual review is a hard gate, not a rubber-stamp.

Each mini-app runs as an isolated workload with its own namespace, restrictive network policies, enforced resource limits, and secrets delivered by secure injection rather than baked into images; health probes and autoscaling keep it self-healing without operator intervention.

Pattern view — a multi-stage delivery gate and a sandboxed runtime where every native capability is mediated by a permission bridge.

Identity

Two-tier identity model: basic identity (OTP) for low-risk services, high-assurance SSO for sensitive ones (anything touching identity, payments, or licence state). Each mini-app is issued its own encryption key alongside its authorised claims, so sensitive payloads are decryptable only with key material scoped to that specific mini-app — an intercepted token alone cannot unlock the data.

Trade-offs

Container-based hosting is a deliberate trade: it gives third-party teams real backend capability and isolation at the cost of higher resource use and operational complexity, so lightweight mini-apps that need no backend can instead ship through a simpler package-based path.

Outcome

A controlled extensibility surface for the Super App. Third-party teams can ship — but only through the gate, never around it.