A cloud IDE training cohort gives every learner the same browser-based development environment on day one: same editor, same toolchain, same starter repo, and the same network path to GitLab and Kubernetes labs. DarDevLab runs instructor-led cohorts on DarDevCDE so instructors teach concepts instead of debugging laptop installs, and demo day becomes a repeatable showcase rather than a scramble to fix one student's broken Docker daemon.
This guide describes how we structure cohorts, run demo days, and reset environments for client or employer demos. It complements our problem statement on why CDEs exist and our onboarding article on eliminating laptop drift for engineers joining product teams.
Why cohorts need a shared cloud IDE
Bootcamps fail in week one when half the room cannot clone a repo or run a container. A cloud IDE training cohort removes that variance: identical workspaces, support tickets shift from environment issues to learning gaps.
- Identical devcontainer or workspace image pinned per cohort intake
- Pre-wired GitLab SSO and lab cluster credentials scoped to the cohort namespace
- Persistent home directory per student for the program duration
- Snapshot or export path for portfolio review after graduation
DarDevLab cohorts target cloud-native skills—Docker, Kubernetes, GitLab CI, observability stacks aligned with dardev.net/products. Students practice on the same reference toolchain DarDev engineers use internally, which is Deployed Realities for education: we teach what we operate, not abstract slides.
Cohort structure: eight to twelve weeks
We run cohorts in three phases: weeks 1–3 fundamentals (Git, containers, first deploy), weeks 4–8 project work in a cohort monorepo with weekly code review, weeks 9–12 capstone polish and demo rehearsal.
- Pre-cohort provisioning
Create cohort workspace template, student accounts, GitLab group, and Kubernetes namespace. Send login links forty-eight hours before kickoff so day one starts in the IDE, not in IT setup.
- Weekly rhythm
Two live sessions (concept + lab), one async assignment with automated CI checks, one office hour block. Recordings stay in DarDevLab; environments remain available for replay.
- Mid-cohort checkpoint
Week five demo: five-minute working deploy per team. Instructors use this to reallocate mentoring before capstone crunch.
- Capstone lock
Week ten: feature freeze on cohort repos. Weeks eleven and twelve are polish, README, architecture diagram, and demo script only.
Demo day format that employers trust
Demo day is not a slide deck marathon. Each team gets twelve minutes: three minutes context, six minutes live demo from the cloud IDE (browser tab projected or shared screen), three minutes Q&A. Judges—employers, DarDev engineers, alumni—score on working software, clarity of trade-offs, and ability to debug live. We require demos to run from the cohort workspace URL so there is no hidden local-only setup; if it works in the CDE, it is reproducible.
- Submit demo script and architecture one-pager forty-eight hours before event
- Open workspace in incognito to prove cold-start reliability
- Show CI pipeline green on the commit being demonstrated
- Keep a rollback tag if the live path fails—honesty beats faking uptime
Student outcomes we track
- Reproducible deploy from README by a peer reviewer
- Green CI blocking merge; no manual prod kubectl
- Capstone repo with runbook, health check, and one metric explained on demo day
- Portfolio link employers can evaluate in under fifteen minutes
Client and prospect demos on DarDevCDE
Training cohorts and sales demos share infrastructure but not data. For client demos—showing DarDevLab labs, a Kubernetes walkthrough, or a Hesabi-adjacent integration prototype—we spin ephemeral demo workspaces from a golden template. The template includes sample data, no production secrets, and auto-destroy after twenty-four hours. Sales engineers never demo from a laptop that worked yesterday but fails on hotel Wi-Fi today.
Reset playbook: clone template, assign guest URL with time-boxed token, smoke-test before the call, revoke and destroy after. Extend TTL for multi-session evals—never mutate one workspace across prospects.
Instructors need cohort-admin visibility: restart stuck containers, push patched devcontainer images, broadcast maintenance windows. Student environments use scoped service accounts—never cluster-admin tokens. See our browser VS Code security article for TLS and session isolation before guest demos.
How DarDevCDE fits DarDevLab
DarDevLab delivers curriculum and progress; DarDevCDE delivers the hands-on surface. Signup stays on dardevlab.com; platform overview on dardev.net/products. Pilot one week with ten learners before a full intake.
How many students per cohort workspace cluster?
DarDevLab targets fifteen to twenty-five learners per intake with one shared lab cluster namespace per cohort. Beyond thirty, split into two cohorts or add a second lab cluster—contention on shared services shows up in CI queue latency before CPU charts complain.
Do students need powerful laptops?
Any machine with a modern browser and stable internet is enough. Heavy builds run in the cloud workspace; laptops are for video calls and notes. This is the same principle as engineer onboarding without laptop drift for product teams.
What if a demo fails live on demo day?
Teams keep a known-good git tag and a thirty-second fallback path—screenshot or recorded clip from rehearsal. Judges reward transparent recovery over silent failure. Cold-start rehearsal in incognito is mandatory.
Can we reuse cohort templates for corporate training?
Yes. Clone the cohort devcontainer and lab module, strip DarDevLab branding if white-label contract requires, and shorten the calendar to one-week intensives. Reset templates between client engagements; never mix prospect data with student cohorts.
Where do I evaluate DarDevCDE for my organization?
Read the cloud development environments problem statement, then contact DarDev via news.dardev.net or dardev.net—routed to Twenty CRM. EscaHire remains waitlist; this guide covers education and demo use cases only.
