RAD provisions Google Cloud infrastructure as plain Terraform into your organisation's own projects, under your own org policies. It is a deploy accelerator, not a management plane you become dependent on — and it is in beta.
Nothing here is anyone's fault. It is what happens when six squads each need Google Cloud infrastructure in the same quarter and there is no shared way to get it.
The same service accounts, the same network, the same secret plumbing, written again by a team that could not find the last version or did not trust it.
Six copies that started identical and are now six different answers to the same question, each one a separate thing to patch when something changes.
Security reviews the same pattern repeatedly because each squad brings its own variant. The review effort scales with the number of teams, not with the number of patterns.
What is deployed, who deployed it, and what did it cost — three questions with three different sources of truth, none of them complete.
RAD is a catalogue of ready-made Google Cloud deployment options and an engine that provisions them. The engine does not host anything — it writes Terraform into a project you nominate.
Counted 2026-08-17. Most applications ship in both a Cloud Run and a GKE variant, so the operating-model choice stays yours rather than being made for you by the catalogue.
When RAD deploys into your project it runs inside your organisation's policy boundary. It cannot widen that boundary, and a deployment that your policies forbid fails the same way your own pipeline would fail.
Region narrowing applies only to projects RAD creates and manages. In your own project you keep the full set of regions Google offers, and your existing residency rules apply unchanged.
Basic mode asks only for the variables that are genuinely mandatory. Advanced mode exposes the full variable set of the underlying module for the cases where a default is wrong for you.
This is the section to read first if the question in the room is "why would we let a third party near our cloud?" — and it is the section where we tell you the one thing you do not get, before your reviewer finds it.
Read that third row before your security reviewer does. Every deployment's Terraform backend points at RAD's own Cloud Storage bucket, in RAD's project — not at yours — and there is no state download in the product today. So the accurate statement of ownership is narrower than the usual one: the Google Cloud project is yours, the resources are yours, the module source is ordinary Terraform, and the state file that tracks those resources is held by us. If you leave, what you keep is the running infrastructure, in your own project, under your own policies; what you would have to rebuild is the state. For a team whose standard is that every production resource is under its own state file, this is a real objection and the answer is "not today", not a reframing.
RAD does not hold it indefinitely either, and that cuts the other way. After the retention period, a deployment record that has gone untouched in the platform, whose owner has neither signed in during that window nor holds purchased credits, is deleted along with its state — after a warning email that must actually have been sent, or the record is kept. Your resources are not touched by that; only RAD's record of them is.
RAD provisions infrastructure and then steps out of the way. Nothing your users touch resolves to us, so an outage on our side is not an outage on yours.
The resources stay where they are and keep running: they were created in your project, under your policies, by ordinary Terraform. Nothing has to be migrated and nothing stops working. What does not come with you is the state file — it stays in RAD's bucket — so a team that wants to keep managing those resources as code re-adopts them into a state file of its own. That is a real piece of work and we would rather quote it honestly than call the exit free.
Whoever inspects your estate next — an internal audit, an acquirer's technical review, a new platform lead — reads Terraform they already understand rather than learning our abstraction first.
The catalogue also contains 62 pre-composed solutions, defining 291 member deployments drawn from 151 distinct applications across 12 categories. Counted 2026-08-17.
A solution averages 4.7 applications, from three to eight. Members with no prerequisite are queued on confirmation and provision three at a time; a member that consumes another member's Terraform outputs waits for that specific deployment, not for a stage in front of it.
For eight producer-and-consumer pairs, RAD is designed to copy the producer's real Terraform outputs into the consumer's configuration before it builds — Elasticsearch into RAGFlow and Zammad, Ollama and LiteLLM into OpenWebUI, ClickHouse into Plausible, Synapse into Element, Gitea into Woodpecker, Directus into Meilisearch. Those eight pairs appear in eight of the 62 solutions; in the other 54, every connection between members of a solution is integration work your team still does, and the automatic part is a beta capability.
A shared project or a shared service is destroyed after the things living inside it have gone, not before. Getting this ordering wrong is what turns a clean teardown into a set of failed destroys and orphaned resources.
Bring-your-own project is the default for an organisation that already has Google Cloud. The alternative exists for the teams inside your organisation that do not — a proof of concept, a training cohort, an external contributor. Each tier is a separate Google Cloud folder with its own policy set, so one tier's rules cannot drift into another's.
The production tier is governed and quota-bounded, not uncapped: it takes development's ceilings wholesale, because the tier that can spend the most had the least standing between it and the spend. The consequence is one your architects should weigh before choosing it — a workload that legitimately needs more than 48 vCPU or 32 GB of Redis in one region is refused rather than served, and a refusal in production is an outage. Every one of these ceilings is raisable per project on request, which is the handle an uncapped tier would not give you. None of this applies to a project you own: your own quotas are yours.
A RAD-managed project deploys into one region in each of eight geographies: us-central1, europe-north2, northamerica-south1, me-west1, africa-south1, asia-east1, australia-southeast2 and southamerica-west1. africa-south1 is Google Cloud's only African region. Each was selected as the cheapest available region in its geography, measured from the Cloud Billing Catalog API.
Seven opt out — they are named on the catalogue page with the reason. Everything else can be deployed either way.
The minimum is set per tier, appropriate to what that tier can do. Free monthly credits do not satisfy it.
An alert notifies as spend approaches and exceeds the figure. It does not block an API call, and we do not describe it as though it does. The enforcement mechanism is separate and described below.
We hold no security certification or third-party audit attestation, and we will not imply one. What we can do is describe the mechanisms precisely enough for your reviewer to judge them.
What a caller is allowed to do is decided from their stored user record, never from anything the browser sends. A client cannot assert a role it does not hold.
A support agent can see a customer's deployments only while a ticket assigned to them is open. Resolving or closing the ticket ends the access; reopening restores it. There is no standing grant that someone has to remember to revoke.
Raw configuration values and deployment outputs are not readable by support staff at any point, and neither is anything that destroys infrastructure. Reading a deployment across a tenant boundary writes an audit record.
A credit grant, a charge or a manual adjustment is recorded as an audit entry, not merely as a log line.
If a user's purchased credit balance goes negative, RAD is designed to disable Google Cloud billing on the managed project it created, and to restore it once the balance is topped up. It only reverses a suspension it applied itself, so it will never undo a deliberate administrative action.
Every deployment is charged against a credit balance, and every charge is a row you can read and export. Credits are the unit: 10 credits = $1.
Between 40 and 300 credits depending on the module's complexity, and nothing at all for nine of the 354 options, which include the migration, service-mesh and reference-architecture modules. The figure appears in the confirmation step, before anything is provisioned, alongside the balance it will come from.
Charged from how long provisioning actually ran, at a published per-hour credit rate. More than half of recorded deployments finish inside 20 minutes, and more than nine in ten inside 30. A failed build carries no module fee.
Credit history is per-transaction and exportable, so a platform team can attribute spend back to the team or project that caused it rather than reconstructing it from cloud billing alone.
A multi-application solution reserves its cost as a single sum across every member, with a bundle discount of 15% on three to four modules, 20% on five to six and 25% on seven or more.
The catalogue is not a closed set. The same publishing path that brings a partner's module in works for a module of your own.
You connect a GitHub repository containing your own modules. RAD reads the module's variable definitions and renders the same guided form your teams already use for catalogue modules.
An internal pattern and a catalogue module are deployed the same way, charged the same way and recorded the same way — which is the point, because two systems produce two answers to "what is deployed".
If your requirement is that a published module is visible to your organisation and to nobody else, raise it with us as part of an evaluation rather than assuming it. We would rather confirm the exact behaviour with you than promise it on a web page.
Better to read this now than to discover it in week three of an evaluation.
Every module targets Google Cloud. If your requirement is one console spanning several cloud providers, RAD is not that, and governance spread that thinly would not be worth having.
If your organisation has standardised on a different infrastructure language and will not accept Terraform state as an artefact, the catalogue has nothing to give you.
The catalogue, the engine and the documentation are built and running. Newer features — cohort provisioning and trainer roles, shipped in August 2026 — are early access, and we label them that way.
RAD earns its keep across many deployments and many teams. For a single small application that one engineer will maintain forever, writing the Terraform yourself is cheaper and we will say so.
The evaluation that settles the argument is not a demo. It is one module, into one project you already own, reviewed by the person who would have to sign it off.
Use one that carries your real org policies. If a policy blocks the deployment, that is the evaluation working — you have just proved RAD cannot widen your boundary.
Open the resources in your own console, alongside the module's configuration guide and the outputs and build log RAD publishes for the deployment. Judge what was created as you would judge a submission from a team. The state file is not yours to open — it sits in RAD's bucket — so judge the resources, not the state.
The ordering on the way down is where estate orchestration is either real or not. Watch the shared foundation go last.
Export the credit history for the week and check it reconciles against what you saw deployed.
Everything a reviewer usually asks for is on this site or in the documentation. There is no gated pack, and nothing here is behind a form.
354 deployment options, 190 applications and platform modules, and the seven that cannot use a managed project.
Modules346 hands-on labs, 523 module configuration guides and 41 certification study guides across 7 Google Cloud tracks.
Open the docsOwnership, lock-in, what a spend alert does not do, who can see your deployments, and whether RAD is production-ready.
FAQTell us which project you want to deploy into and which pattern your teams keep rewriting. We will help you get one module into one of your own projects this week.
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.