EdTech · Platform Engineering · 2025
Kubernetes platform for an AI-powered university learning system
Full platform engineering for funiver.ai — a university AI learning companion platform built on microservices. Kubernetes deployment, Helm-based service management, Keycloak identity layer, GitLab CI/CD with multi-stage security scanning, and a canary-to-production incremental rollout strategy.
- 7Microservices
- CanaryRollout strategy
- 4-stageSecurity pipeline
- ZeroManual deploys
Context
An AI education platform that needed production-grade infrastructure
funiver.ai is an AI-powered learning companion platform for universities — personalising student education, extending faculty reach, and connecting students with career opportunities. As the product moved from prototype to production, the team needed a cloud-native platform that could support independent service deployments, enforce security policies, and scale without operational overhead.
Challenge
Seven services, one coherent platform, non-negotiable security
The backend was split across seven independent .NET microservices plus a Next.js frontend, each requiring its own build, image, and deployment lifecycle. Authentication had to be centralised through Keycloak without coupling service code. The CI pipeline needed full security scanning — SAST, DAST, container scanning, and dependency analysis — with a hard gate preventing deployment of images with High or Critical CVEs.
Solution
Helm-managed microservices with a security-gated CI/CD pipeline
We designed the full platform layer: Kubernetes namespace strategy, per-service Helm charts, a multi-stage GitLab CI pipeline with security enforcement, and a canary-based incremental rollout to production.
Kubernetes & Helm
Each of the seven services — BFF, Courses, Lessons, UserProfile, UserCoursesData, YARP API Gateway, and Next.js Frontend — deployed via independent Helm charts into a dedicated namespace. Keycloak, MinIO, and PostgreSQL provisioned in isolated namespaces with credential management through Kubernetes secrets.
CI/CD pipeline
GitLab CI with 15 stages: secret detection, pre-build checks, parallel service builds, a build gate, security scans (SAST, DAST, container scanning, dependency scanning), a security gate blocking on any High/Critical finding, deployment, post-deploy DAST, and an incremental rollout from canary through 10%, 25%, 50% to 100% production traffic.
Identity & access
Keycloak deployed as the central IAM layer — realm configuration automated via CI, BFF service handling token exchange between frontend and backend services. All inter-service communication routed through the YARP API Gateway with Keycloak-issued tokens.
Observability
Grafana Alloy deployed as the metrics and log collection agent, shipping to Grafana Cloud. Ollama running locally in-cluster for AI inference workloads, with MinIO providing S3-compatible object storage for course assets.
Engineering approach
How we delivered
Architecture
Defined namespace topology, service boundaries, and inter-service communication model. Designed Keycloak realm structure and YARP routing rules before any deployment.
CI/CD foundation
Built the GitLab CI pipeline skeleton with build templates, Helm deploy templates, and security scan integration. Established the security gate policy against High/Critical CVEs.
Service rollout
Deployed infrastructure services first (PostgreSQL, Keycloak, MinIO), then onboarded all application microservices via Helm. Validated inter-service authentication end-to-end.
Production hardening
Implemented canary and incremental rollout stages, connected Grafana Alloy for full observability, and documented operational runbooks for each service.
Results
Measured impact
- 7Services in production
- 15CI/CD pipeline stages
- 0High/Critical CVEs in prod
- CanaryIncremental rollout
- 100%Automated deployments
Project views
Product & platform views
Technology
Stack & capabilities
Facing a similar challenge?
Start a project