You choose an application or solution from the catalogue, and RAD provisions it into a Google Cloud project — one you already own, or one RAD creates and governs for you.
Five steps. No need to write infrastructure code.
The catalogue holds 350+ deployment options covering 190+ applications and platform modules. Most applications ship in both a Cloud Run and a GKE variant.
Basic mode shows only the variables the module marks as mandatory, and a first deployment is always Basic. The full variable set opens on update, once you buy credits.
The module fee depends on the module's complexity, and is shown on the confirmation screen. Build cost are always metered and charged.
RAD runs Terraform as a provisioning job against your project. Build logs stream into the console while it runs, enabling users to view status in realtime.
The module's Terraform outputs are published against the deployment. The state is not: it lives in RAD's own Cloud Storage bucket from where updates can be performed.
The stage that broke is marked, the stages after it stay queued rather than running against a half-built foundation, and the Terraform output that produced the error sits underneath it. The whole log is searchable and downloadable.
Opens a Google AI Mode search already seeded with that step's own error output, so you are not copying a stack trace into a search box or describing it from memory.
Raises a support ticket with the failure context attached. One route is instant and self-service, the other reaches a person; which you want depends on how legible the error is.
A deployment you cancelled yourself does not offer either action, because there is nothing to look up. They appear on a step that genuinely failed.
A deployment is not a one-way door. Three actions cover its lifecycle, and one of them is the exit.
Change the module's configuration and re-apply. Terraform plans and applies the difference rather than rebuilding from scratch, so what is already running is left where it is. The build cost of the update is metered.
Some fields cannot change without rebuilding what they created, so changing one raises a confirmation before anything runs. An administrator can instead make those fields read-only while a deployment is running.
Destroys the cloud resources the module created, in dependency order. Resources shared with other module deployments — a project, a network — are retained, so a shared foundation outlives what ran inside it.
Removes RAD's record of the deployment and its Terraform state, and runs no Terraform. In a project you own you can purge while the infrastructure keeps running; in a RAD-managed project the delete has to finish first, because those resources bill RAD.
RAD applies a retention period: once a deployment has been unused for longer than that period, and its owner has neither signed in within the window nor holds any purchased credits, RAD deletes the record and the Terraform state along with it. A warning email goes out to each user. Deployments in a RAD-managed project are exempt from the sweep entirely, as are the records of the managed projects themselves. Retention removes configuration records: your Google Cloud resources are untouched by it and stay running.
A solution is a pre-composed bundle of applications deployed as a single dependency-ordered unit, holding between three and eight of them.
Members without a dependency queued the moment the deployment is confirmed, with three provisioning at a time. A member that consumes another member's outputs waits for the dependencies to be successfully deployed.
Where a wiring recipe is defined for a producer-and-consumer pair, the producer's outputs are read and written into the consumer's configuration before it deploys. Other members of a solution take their configuration from the form, and some may need manual configuration following deployment.
Destroying a bundle does not fire every teardown at once. A shared foundation is parked behind resources that depend on it. This ordering stops a project being deleted before its members.
Deployment credits for every member are reserved before the first member deployment starts, so a bundle cannot get halfway in and stop for want of balance. Multi-module solutions are discounted.
Wiring is defined per producer-and-consumer pair. Additional configuration may be required after the deployment finishes. Examples are listed here:
Two targets, and the catalogue and engine are identical for both.
RAD deploys as a principal inside your Google Cloud project, subject to your organisation's policies and unable to widen them. Every Google Cloud region is available to you; region narrowing is a property of RAD-managed projects only. RAD holds and manages the deployment configuration, and the Terraform state used to deploy into your project is stored in RAD's own Cloud Storage bucket rather than in yours.
If you have no Google Cloud account, RAD creates a project for you in one of four tiers, each in its own Google Cloud folder with its own organisation-policy set. Creating one requires a minimum purchased credit balance for that tier, and you may hold one managed project per tier at a time. The project's Google Cloud spend is recharged to your credit balance, as Google reports it.
Separate folders are the point: a relaxation made for one tier cannot drift into another. Lab carries the sandbox policy set deliberately, in a folder of its own, so a cohort cannot reach into a customer's own sandbox.
One region in each of eight geographies. Each was picked as the cheapest available region in that geography, measured from the Cloud Billing Catalog API rather than chosen by reputation. africa-south1 is the only Google Cloud region on the African continent. In your own project none of this applies — you keep every region Google offers.
Mechanisms, not adjectives. These are the controls applied to the sandbox and lab tiers, which carry the tightest set.
The same credential-hygiene floors apply. An external IP is permitted only where OS Login and Shielded VM are in force; a publicly readable bucket only where uniform bucket-level access is on; a public database IP only through the Cloud SQL Auth Proxy, because authorised networks are blocked outright. Developers can configure enabled Google Cloud services.
Production is not the uncapped tier. It takes development's quota set wholesale: 48 Compute Engine vCPU and 32 Cloud Run vCPU per region, 32 GB of Memorystore Redis per region, 1 TiB of BigQuery scan per day. A value above one of those ceilings is refused when you submit the form, naming the ceiling it exceeded. Quotas can be increased on request.
Nobody picks the lab tier from a list — it appears on no deploy form. It follows from deploying for participants: attach a roster, choose who the deployment is for, and each participant's project lands in lab. Only trainers and administrators can do that, and each deployment's credits are debited from that participant's own balance, never the trainer's.
These access rules are enforced by the server on every request.
What you are allowed to do is read from your stored user record on the server, on every request — never from anything the browser sends. A modified client asks the same questions and gets the same answers.
A support agent can see your deployments only while a ticket of yours is assigned to them and still open. Resolving or closing it ends the access — at once in the console, and within five minutes on the API; reopening restores it.
Raw configuration values and deployment outputs are excluded from support access, as is anything destructive — support cannot tear down what it can see.
Credit grants, adjustments and revenue splits write an audit record, and cross-tenant support reads of a deployment's status, logs or credit history are recorded too.
Three separate mechanisms that are often collapsed into one word. They do different things and one of them does less than people assume.
You are charged for the resources needed to perform the deployment, measured from its real duration at a published per-hour credit rate. The cost is deducted once the build finishes, so you pay for the time it actually took rather than an estimate. The module fee is separate, and is shown for review before you confirm.
Each tier carries a monthly Google Cloud budget that raises alerts as spend approaches and then exceeds it. Those alerts reach our administrators and finance team, not the project's user, because the spend lands on our billing account. A budget notifies; it does not refuse an API call, and raising one permits no extra spend.
RAD is designed to disable billing on a managed project when the account's purchased credit balance goes negative, and to restore it once the balance is topped up. It checks on a fifteen-minute schedule, and only ever reverses a suspension it applied itself — never one you or Google put in place.
Better to read this now than to discover it in week three.
Every module targets Google Cloud. Governance spread thinly across providers, and the guardrails above exist because there is a tier based policy model to enforce them in.
If your platform standard is a different provisioning tool, RAD's output stays legible to you, but it will not be native to your pipeline — you would be adopting Terraform alongside what you already run.
RAD-managed tier's organisation policy may not permit some modules and solutions to be deployed into a RAD project. You can deploy these modules into a Google Cloud project you already control.
The catalogue, the deployment engine and the documentation are built and running. Newer parts may be early access and labelled as such on the pages that describe them.
If your requirement is a small application and nothing else, a shared host will cost less than a governed Google Cloud project plus a module fee. RAD earns its price on estates, on governance you would otherwise build.
Everything above is the same whoever you are. What it is worth depends on what you deploy and how often — pick the closest fit.
One reviewed catalogue deployed into projects your organisation already governs, as ordinary Terraform.
The estate a product needs, in your own project or in a governed one RAD creates if you have no GCP account.
A real project and a real deployment per participant, provisioned for a cohort in one action. Early access.
Make your software deployable on Google Cloud from one form, or publish and deploy your own Terraform modules.
It is the fastest way to check any of this for yourself. Signing up gives you 300 credits and does not ask for a payment method.