GitOps on AWS EKS: Deploying ClassKira's Multi-Tenant SaaS LMS

Scaling a modern Software-as-a-Service (SaaS) application requires balancing resource efficiency with strict security. In the educational sector, this challenge is amplified. Educational platforms experience massive spikes in traffic during active class hours and exam periods, followed by complete silence at night. Furthermore, schools and universities demand absolute data isolation—no student or administrator should ever see data belonging to another institution.

This case study dissects the architectural design and deployment flow of classkira.com, a leading multi-tenant Learning Management System (LMS) SaaS. We will explore how it utilizes a database-per-tenant architecture, runs efficiently on AWS Elastic Kubernetes Service (EKS), secures connections via GitHub OIDC, and automates continuous deployments using GitOps with Argo CD.

In a single-tenant architecture, each customer gets their own separate server and database. While secure, this is incredibly expensive to maintain and update. In contrast, multi-tenancy allows multiple customers (called "tenants") to share the same computing infrastructure, drastically reducing operational costs.

For ClassKira, multi-tenancy is structured around a "Shared Compute, Isolated Data" model:

• Subdomain Routing: Each school receives a custom subdomain (e.g., academy.classkira.com, school-a.classkira.com).
• Shared Application Pool: All incoming requests hit the same pool of Laravel containers running inside AWS EKS, avoiding the overhead of maintaining individual servers for every academy.
• Dynamic Database Routing: At the application level, a custom Laravel middleware identifies the tenant based on the incoming subdomain host header. It instantly switches the active database connection to that specific tenant's dedicated database schema (Database-per-Tenant model).

Deploying updates in a multi-tenant environment is high-stakes. A single broken deployment doesn't just affect one user; it can instantly halt operations for hundreds of schools, locking thousands of teachers and students out of classrooms.

To mitigate this risk, ClassKira relies on AWS Elastic Kubernetes Service (EKS) coupled with a strict GitOps continuous delivery pipeline:

1. Infrastructure elasticity: Kubernetes allows ClassKira to scale container pods up in seconds during peak morning logins, and scale them down to a minimum configuration overnight to save costs.
2. Declarative State: With GitOps, the desired state of the EKS cluster is fully written out in YAML manifest files inside a Git repository. We don't log into servers to run commands. Git is the single source of truth.
3. Continuous Reconciliation: Argo CD runs inside EKS, continuously comparing the live cluster state with the declared files in Git. If someone manually alters a setting in EKS, Argo CD immediately detects the drift and overrides it back to the Git-defined configuration.

Traditional CI/CD pipelines require storing long-lived credentials (like AWS_ACCESS_KEY_ID) in GitHub secrets. If a developer account or repository is compromised, those credentials can leak, giving hackers administrative access to the entire AWS account.

ClassKira solves this using OpenID Connect (OIDC) and AWS STS (Security Token Service) to implement a passwordless, short-lived trust relationship:

Because the generated credentials expire automatically after a short period (typically 1 hour), there are no permanent keys to be stolen, making the system incredibly resilient to credential leaks.

From a developer committing code to a live update in production, the ClassKira pipeline operates as a fully automated conveyor belt. Let's trace the steps of a code change:

No matter how thoroughly code is tested, production failures can happen—especially in a high-stakes multi-tenant environment. When a regression slips through, the priority is minimizing the Mean Time to Recovery (MTTR). In a GitOps architecture, rolling back changes is safe, structured, and auditable.

ClassKira uses a two-tier rollback strategy depending on the severity of the failure:

1. The GitOps-Native Rollback (Preferred Strategy)

Because Git is the source of truth, the cleanest way to roll back is to declare the rollback in Git. If a buggy deployment is detected, engineers perform a Git revert on the manifest repository:

2. The "Break-Glass" Emergency Rollback

If Git is temporarily inaccessible, or if the pipeline is blocked and every second counts to prevent downtime, engineers bypass the pipeline for immediate recovery:

• Step A: Disable Argo CD Auto-Sync: Engineers pause Argo CD's auto-sync setting using the CLI or dashboard. This prevents Argo CD from fighting manual intervention and trying to re-apply the buggy Git configuration.
• Step B: Rollback via Kubernetes: Run the native Kubernetes rollout command to instantly switch the deployment back to the previous revision:
  kubectl rollout undo deployment/classkira-app
  This directs EKS to immediately stop the buggy pods and spin the previous healthy replica set back up.
• Step C: Resolve and Re-enable Sync: Once the system is stable, engineers diagnose the issue, push a clean fix to Git, and re-enable Argo CD auto-sync to let the standard pipeline resume control.

When teachers, students, and parents open ClassKira, their browsers establish connections directly to the production cluster. Here is the step-by-step route internet traffic takes:

How ClassKira Dynamic Auto-Scaling Works:

• Pod Auto-scaling (HPA): The Kubernetes Horizontal Pod Autoscaler (HPA) watches the CPU/Memory utilization of ClassKira pods. If usage crosses 70%, HPA commands EKS to scale up pod counts (e.g., from 3 to 10 replicas).
• Node Auto-scaling (Karpenter): If the EKS cluster lacks the CPU/Memory capacity to schedule these new pods, Karpenter acts immediately, provisioning new EC2 instances in less than 30 seconds and joining them to the cluster.
• Shrinking Capacity: As traffic drops in the evening, the reverse process occurs. Karpenter terminates idle EC2 instances and EKS deletes unused pods, ensuring ClassKira only pays for what it actually uses.

For a production-grade multi-tenant SaaS, the infrastructure must be partitioned across several secure, scalable tiers. Below is the interactive blueprint representing ClassKira's full-scale architecture. Toggle between the tabs to explore the Infrastructure Blueprint, follow the Code-to-Cloud GitOps Pipeline, or deep-dive into the Multi-Tenant Data Isolation design.

on:
  push:
    branches: [ main ]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run PHPUnit Tests
        run: php artisan test

ClassKira's EKS GitOps deployment strategy showcases the maturity of modern cloud-native systems. By separating concerns—using GitHub Actions strictly to build/test, and Argo CD to enforce EKS state—the platform gains stability and auditability. Combined with temporary OIDC token exchanges and strict database-per-tenant isolation, ClassKira delivers a highly secure, reliable, and cost-effective LMS SaaS for educational organizations worldwide.