DarDevLab cohorts run on the same DarDevOps Kubernetes clusters we use for internal SaaS—not a separate education stack on generic hosting. When an intake opens, platform engineers provision namespaced lab environments, wire GitLab groups, and attach DarDevCDE workspaces so learners can kubectl apply on day three without installing Docker locally.
We organize delivery around Authorize, Develop, Deploy, Observe: Workspace IAM controls who can touch cohort namespaces, DarDevCDE supplies consistent dev environments, DarDevOps clusters host the runtime, and Prometheus plus Grafana tell us whether a lab API or workspace pool is degrading mid-cohort. That loop is why we describe DarDevLab as Deployed Realities for education—we operate the platform we teach.
Platform stack: app tier, lab tier, learner workspaces
Three layers stay deliberately separate so a buggy capstone deploy cannot take down billing or enrollment.
- Application tier: dardevlab.com services—auth, catalog, progress tracking, payments—deployed through the same GitLab CI → image → staging → production path we document in Building a Kubernetes-native product pipeline
- Lab tier: per-cohort Kubernetes namespaces with ResourceQuota, NetworkPolicy, and RBAC scoped to student service accounts—not cluster-admin tokens handed out in week one
- Learner workspaces: DarDevCDE browser IDEs with pinned devcontainer images, GitLab SSO, and pre-seeded repos; reset or snapshot between intakes as described in CDE training cohorts and demo days
Signup and billing remain on dardevlab.com. Product news for enrolled learners routes through CRM tags to private Listmonk lists; marketing interest uses mail.dardev.net subscribe forms. Outbound mail for campaigns uses send.dardev.net—never the root @dardev.net domain reserved for inbound Zoho mail.
Provisioning a cohort: namespaces, quotas, and reset
Before kickoff, automation creates a cohort slug, GitLab subgroup, and Kubernetes namespace with curriculum-matched limits. Fundamentals tracks cap CPU and memory per student; capstone tracks get higher ceilings but never cluster-admin kubeconfig.
NetworkPolicy denies east-west traffic between cohort namespaces. Students reach only their namespace, shared lab services, and GitLab. After cohort end we export portfolios, revoke credentials, delete ephemeral PVCs, and reset namespaces per a git-tracked checklist—reusing without reset leaves last cohort's Secrets behind.
Shipping DarDevLab releases without classroom downtime
Feature work on the learning app follows guarded promotion. Merge requests run tests; main builds an immutable image tagged with the commit SHA; staging receives the deploy first with readiness probes on real dependencies (Postgres, Redis, object storage). Production promote is manual during active cohort weeks unless the change is a documented hotfix with rollback rehearsed.
Lab-side changes—new Helm chart for a Prometheus exercise, updated ingress for a service-mesh module—ship as versioned manifests in the cohort monorepo, not ad hoc kubectl from an instructor laptop. CI jobs use namespace-scoped tokens; the anti-pattern we call out in our GitLab CI to Kubernetes guide applies here too: cluster-admin pipeline credentials are an audit finding, not a convenience.
Observability when two hundred learners hit the API
Live cohorts spike workspace boots, lab webhooks, and GitLab CI. We treat DarDevLab like any production tenant—error ratio and pool saturation on dashboards, deploy annotations in Prometheus, alerts to the same on-call rotation covering internal SaaS stacks.
Logs, metrics, and traces follow the same conventions we publish in logs, metrics, and traces: structured JSON from app pods, kube-state metrics for quota exhaustion, and trace IDs propagated from the dardevlab.com edge through lab APIs. When p95 latency climbs during a Tuesday lecture, we scale the workspace pool or throttle non-critical jobs—not ask students to refresh until someone notices in Slack.
Why we chose Kubernetes for education infrastructure
DarDevLab teaches Docker, Kubernetes, GitLab, and observability because those are the skills MENA engineering teams hire for—not proprietary trivia. Running cohort labs on the same primitives students will see at work makes exercises credible. Our longer rationale lives in why Kubernetes at DarDev; the short version: portable skills, git-defined infrastructure, and one operational playbook for products and classrooms.
Boundaries we keep strict
- No colocated production customer data inside learner namespaces
- No marketing-list adds from CRM until documented product opt-in
- No floating latest image tags on dardevlab.com production manifests
- No instructor kubectl apply to shared platform namespaces during class
- No claiming waitlist products as generally available in learner-facing copy
Teams evaluating similar setups can start with one cohort namespace, one staging environment, and one manual production gate—then expand. DarDev documents platform patterns on dardev.net/products and ships cohort infrastructure for DarDevLab intakes throughout the year; contact us for enterprise cohort or private lab contracts.
Does each DarDevLab cohort get its own Kubernetes cluster?
Usually no. Cohorts get isolated namespaces, RBAC, and NetworkPolicy on shared DarDevOps clusters. Separate clusters are reserved for regulated client contracts or blast-radius requirements—not typical public intakes.
How is this different from the CDE training cohorts article?
The CDE article covers pedagogy, demo day rhythm, and workspace templates for instructors. This case-study focuses on DarDevOps infrastructure—namespaces, CI/CD, quotas, observability, and release discipline behind dardevlab.com.
Where do students create accounts?
On dardevlab.com. Email opt-in for product news is separate from marketing subscribe forms at mail.dardev.net. CRM tags drive private news lists after documented consent.
What happens to lab resources after a cohort ends?
Credentials revoke, ephemeral volumes delete, and namespaces reset per runbook. Portfolio exports are retained per student request; shared metrics inform the next intake capacity plan.
Can employers run private cohorts on the same platform?
Yes. DarDev provisions employer-branded intakes with the same isolation and observability patterns. Scope private contracts through dardev.net/products or the news.dardev.net contact form routed to Twenty CRM.
