RAD provisions one real Google Cloud project and one real deployment per participant, from a roster of up to 30, in a single action. No participant needs a Google Cloud billing account. Cohort provisioning is early access.
Every trainer who teaches cloud recognises all four.
A learner who has already used the real console sees the seams. A learner who has not is taught something that does not exist outside the classroom.
One learner deletes a network or exhausts an address range, and the exercise stops for the other twenty-nine. You debug your own lab rather than teach.
Card details, a billing account per person, and a bill that runs long after the course ends. In several markets the learner cannot complete that step at all, and never starts.
A day of setup before every cohort, and scripts that drifted since the last one. The infrastructure is real, but you author it again for each delivery.
There is also cleanup, after everyone has gone home: finding what was left running, in whose account, and turning it off before it becomes an invoice.
The ordinary RAD deploy form, with a roster attached.
You send us the participant addresses and an administrator enters them against your trainer account. Membership is checked again on every request, so an addition works immediately and a removal ends access immediately.
Thirty is the maximum a cohort accepts, and a longer list is refused on save rather than quietly trimmed. Larger intakes run as more than one cohort. The deploy form offers exactly those addresses, so a trainer cannot name someone off it.
The same form any user fills in: pick a module from the catalogue of 350+ deployment options covering 190+ applications and platform modules, answer the questions that differ between installations, confirm. There is no separate trainer console.
Each participant gets their own Google Cloud project and their own deployment inside it. Not a shared project with thirty namespaces: thirty projects.
RAD-managed projects are created in one of four Google Cloud folders: sandbox, development, production and lab. Each has its own org-policy set. Lab is available to trainers and administrators; ordinary users may self-select the other three.
Participants work in standard infrastructure in a project they own, provisioned by ordinary Terraform. Nothing they learn only exists inside RAD. The Terraform state is held in RAD's Cloud Storage rather than the participant's project.
Delete destroys the resources. You provisioned them and you can see them, so nothing is left running to hunt for later.
This is the ordinary deploy form. The only difference is the panel at the top: pick the participants, and one confirmation provisions one project and one deployment for each of them. There is no separate trainer console.
Deploy-on-behalf works only into RAD-managed projects. Switching the RAD-managed option off clears the participants you had selected. A trainer cannot provision into a participant's own Google Cloud account.
Org policies applied to the folder the lab projects are created in.
One region in each of eight geographies, the cheapest available in that geography per the Cloud Billing Catalog API. africa-south1 is the only Google Cloud region on the African continent.
A deployment into a participant's own project keeps every region Google offers.
Ownership and cost both sit with the participant, not the trainer.
Not the trainer, and not RAD. When the course ends, what they built is theirs, in a project registered to them, as ordinary Terraform.
Each participant needs their own funded RAD account. A trainer action does not become a single trainer invoice. Signing up gives each person 300 credits with no payment method required, and 100 credits monthly after that.
10 credits is $1. A deployment is charged as a module fee, which depends on the module's complexity and is shown before anyone confirms, plus a build cost of 60 credits an hour metered from how long provisioning ran.
Most modules build in well under half an hour, so budget the module fee plus a modest build cost per participant.
RAD takes payment through Stripe and Flutterwave; Flutterwave supports card, bank transfer, USSD and mobile money. RAD never handles card details, and credits are granted only after the provider confirms the payment.
A user may hold one RAD-managed project per tier, so a participant can have a lab project from your cohort and their own sandbox project at the same time.
The trainer role on its own grants nothing. Visibility is derived from the roster, and it is re-checked on every request.
A roster stands until someone clears it. Ask an administrator to empty the list at the end of term, or to strike a single name for a participant who leaves in week two.
Access is derived from membership rather than held as a separate permission, so that one edit is the whole revocation, and it takes effect on the next request.
The catalogue carries 60+ pre-composed solutions, and a solution can be provisioned for a cohort in the same way a single module can.
A solution holds between three and eight applications, provisioned three at a time into one project. A member that consumes another member's Terraform outputs waits for that deployment to finish; the rest start as soon as the solution is confirmed.
Where a producer-and-consumer pair is wired, a solution writes the producer's Terraform outputs into the consumer's configuration when it finishes. Connections in other solutions are made by hand. This wiring is a beta capability; verify it in a pilot.
Teardown runs the dependency graph backwards, so the shared project is destroyed after the things living inside it rather than before them. For a cohort that is the difference between a clean end of term and a set of half-deleted estates left to chase.
A capstone solution is charged as one reservation across all its members, with a bundle discount of 15% for 3–4 modules, 20% for 5–6 and 25% for 7 or more. Debited, as always, from each participant.
Page counts from docs.radmodules.dev.
Each one ends in something running rather than in a diagram. They map onto the same catalogue your cohort deploys from, so the lab a participant reads and the form they fill in are the same subject, step for step, throughout.
One for each of the 345+ application options, plus 175+ shared application-layer guides those options build on. They list the variables the deploy form asks about and what each one does, which makes them useful as pre-reading.
Aligned to seven Google Cloud certification tracks: ACE, PCA, PCD, PCDE, PCNE, PDE and PSE. Each guide defines deployment profiles built from the foundation modules and maps the exam domains onto them for teaching.
The brochure is the version to send a head of faculty or a budget holder: what the lab tier restricts, and how a course is costed per seat. There is also a programme write-up, From Certified to Capable, for the curriculum itself.
RAD is in beta, and cohort provisioning is the newest part of it.
The trainer role, the roster and the lab tier are built and running. They have not yet been through a role-based security review, and one scoping bug has already been found and fixed.
If your curriculum needs another cloud provider, RAD is the wrong tool. Everything in the catalogue is a Terraform module targeting Google Cloud.
Free signup credits cover an exercise or two per person. Sustained cohort use does not run on the free tier, and there is currently no way to pay for a whole cohort from one trainer account.
Training providers, university lecturers, bootcamp operators and corporate L&D teams who will run one real cohort with us. In exchange you get direct access to the people building it, and your feedback lands in the product.