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 shipped in August 2026 and is early access.
Every trainer who teaches cloud recognises all four, and none of them is good.
Nobody in the room believes it. The learner who has already used the real console can see the seams, and the learner who has not is being taught a thing that does not exist outside the classroom.
One learner deletes a network, changes a quota or exhausts an address range, and the exercise stops for the other twenty-nine. You spend the afternoon debugging your own lab rather than teaching.
Which means card details, a billing account per person, and a bill that keeps running long after the course ends. In several of the markets we care about, the learner cannot complete that step at all.
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 and you own every failure in the room.
Then there is the option nobody lists, because it happens after everyone has gone home: cleanup. Finding what was left running, in whose account, and turning it off before it becomes an invoice.
It is the ordinary RAD deploy form, with a roster attached to it.
There is no roster editor in the trainer view. You send us the participant addresses, an administrator enters them against your trainer account, and membership is checked again on every request — so an addition works immediately and a removal ends access immediately. Thirty is the maximum a single cohort accepts, and a longer list is refused on save with a message that says so, rather than quietly trimmed. Larger intakes are run as more than one cohort. On the deploy form you then choose from exactly those addresses: there is no search, so there is no way to name someone who is not on your roster, and the server refuses it if you try.
The same form any user fills in: pick a module from the catalogue of 354 deployment options covering 190 applications and platform modules, answer the questions that genuinely differ between installations, confirm. There is no separate trainer console to learn.
Each participant gets their own Google Cloud project and their own deployment inside it. Not a shared project with thirty namespaces — thirty projects, with the blast radius that implies.
RAD-managed projects are created in one of four Google Cloud folders — sandbox, development, production and lab — each with its own org-policy set, so one tier's rules cannot drift into another's. Lab is available to trainers and administrators; ordinary users may self-select sandbox, development or production.
The environment your participants work in is standard infrastructure in a project they own, provisioned by ordinary Terraform. Nothing they learn is an abstraction that only exists inside RAD. The Terraform state itself is held in RAD's Cloud Storage rather than the participant's project.
Delete destroys the resources. There is no weekend spent hunting for what somebody left running, because you provisioned it and you can see it.
Deploy-on-behalf works only into RAD-managed projects. If the RAD-managed option is switched off, the participants you had selected are cleared from the form with it — a trainer cannot provision into a participant's own Google Cloud account.
Mechanisms, not adjectives. These are org policies applied to the folder the lab projects are created in.
One region in each of eight geographies, chosen as the cheapest available region in that geography as measured from 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.
This is a commercial fact rather than a footnote, so it belongs here rather than at the bottom of a pricing page.
Not the trainer, and not RAD. When the course ends, what they built is theirs, in a project registered to them, as ordinary Terraform.
Say this plainly to your cohort before day one: 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; beyond that they fund their own account.
10 credits is $1. A deployment is charged as a module fee — 40 to 300 credits depending on the module's complexity, nothing at all for nine of the 354 options, and always shown before anyone confirms — plus a build cost metered from how long provisioning actually ran, at 60 credits an hour — one credit a minute. More than half of recorded deployments finish inside 20 minutes, and more than nine in ten inside 30, so that is the range to budget 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. Coming to class does not cost them the environment they already had.
The trainer role on its own grants nothing. Visibility is derived from the roster, and it is re-checked on every request.
A roster does not lapse on its own — it stands until someone clears it. Clearing it is one edit: 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. Because access is derived from membership rather than held as a separate permission, that one edit is the whole revocation, and it takes effect on the next request.
That is also the answer to the question a security reviewer asks: a trainer's reach is a function of one list, held on their own account and maintained by an administrator, and it is recomputed on each request rather than remembered.
The catalogue carries 62 pre-composed solutions, counted 2026-08-17, and a solution can be provisioned for a cohort in the same way a single module can.
A solution averages 4.7 applications, ranging from 3 to 8, provisioned three at a time into one project. A member that consumes another member's Terraform outputs waits for that specific deployment to finish; the rest start as soon as the solution is confirmed. Across all 62 solutions the catalogue defines 291 member deployments drawn from 151 distinct applications.
For eight producer-and-consumer pairs, a solution is designed to write the producer's real Terraform outputs into the consumer's configuration when it finishes — Elasticsearch into RAGFlow and Zammad, Ollama and LiteLLM into OpenWebUI, ClickHouse into Plausible, Synapse into Element, Gitea into Woodpecker, Directus into Meilisearch. Those pairs appear in eight of the 62 solutions; in the other 54 every connection between members is done by hand afterwards, which for a class is a teachable step rather than a gap. The automatic part is a beta capability; verify it in a pilot rather than assume it.
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 thirty half-deleted estates.
A solution deployed as a capstone 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.
Counted 2026-08-17 on docs.radmodules.dev. Every figure below is a page count you can go and check.
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.
One for each of the 346 application options, plus 177 shared foundation guides those options build on. They list the variables the deploy form will ask about and what each one does — useful as pre-reading and as the answer to "what does this field mean?" while you are teaching.
Aligned to seven Google Cloud certification tracks: ACE, PCA, PCD, PCDE, PCNE, PDE and PSE. Each track's guide defines deployment profiles built from the foundation modules and maps the exam domains onto them, so a section can be taught as reading plus a real deployment rather than reading alone.
RAD is in beta, and cohort provisioning is the newest part of it. The honest state of the feature, stated by us rather than discovered by you.
The trainer role, the roster and the lab tier are the newest part of RAD. They 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. We would rather you knew that now than after you had booked a room.
If your curriculum needs another cloud provider, RAD is the wrong tool and we will say so on the call. Everything in the catalogue is a Terraform module targeting Google Cloud.
Worth repeating, because it changes how you price a course. 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 and tell us where it hurts. In exchange you get direct access to the people building it and your feedback lands in the product rather than a backlog.
RAD is in beta. The platform, catalogue and documentation described here are built and running; features marked as early access are newer and we say so where that is true. Catalogue figures counted 2026-08-17.