The questions the other pages could not answer without losing their thread.
Start here if you have never heard of us.
RAD is a deployment platform for Google Cloud. Pick from 350+ deployment options covering 190+ applications and platform modules, and RAD provisions it into a project you own or one RAD creates.
Google Cloud, and nothing else. That is a deliberate limit: the org policy, IAM, networking and guardrails RAD sets up are specific to Google Cloud. If your estate lives elsewhere, RAD is not the right tool.
Rapid Application Development is a 1990s methodology about iterative prototyping. RAD here deploys ready-made infrastructure patterns onto Google Cloud, and the D stands for deployment.
A module is one deployable option: one application in one operating model, written as Terraform with a guided form. 350+ options cover 190+ applications and platform modules, because most applications ship as both a Cloud Run and a GKE variant. See the catalogue.
A solution is a pre-composed bundle of applications deployed into one Google Cloud project; there are more than 60. Members with no prerequisite provision three at a time; one consuming another's outputs waits. Teardown runs in reverse. How solutions work.
The questions a platform team asks first.
Yours, by default. RAD deploys into a project you own, under your organisation's policies, which RAD cannot widen, and you keep every region Google offers. With no Google Cloud account, RAD can instead create and govern one for you, in one of four tiers. In a managed project you buy credits, which are redeemed against its Google Cloud costs.
Yes. Resources in a project you own keep running: they are Google Cloud resources you own. A RAD-managed project is different — it runs on RAD's billing account, and RAD suspends its billing once your credit balance goes negative. The Terraform state stays with RAD, and after a retention period an untouched record is removed with it; your resources are not.
No. The module source is ordinary Terraform, and the resources are ordinary Google Cloud resources in a project you own. The state file and its backend point at RAD's own Cloud Storage bucket. Most modules originate from partner repositories, which are private. RAD publishes one repository of its own as an example, and may publish more at its discretion.
No. RAD provisions the infrastructure and then steps out of the way. Traffic reaches your Google Cloud resources directly; it does not pass through RAD, and RAD being unavailable does not make your deployment unavailable. What stops working is our console, not what you deployed, and what you deployed keeps serving traffic exactly as it did before.
Everything RAD charges for, and the parts Google charges for instead. Full detail on the pricing page.
Two parts: a module fee shown before you confirm, plus a build cost for provisioning time. Credits are priced at 10 to the US dollar, and build time at 60 an hour. Google Cloud resources bill to the project.
A failed build carries no module fee: you are not charged for a deployment that did not deploy. You can read the same build log an engineer would, to work out what went wrong.
It depends which of three balances they sit in. Free award credits refresh monthly and do not accumulate. Subscription credits roll over. Credits bought outright never expire. Spending draws on the soonest-to-expire balance first.
You get 300 credits when you sign up and 100 each month after that, with no payment method required. Free users deploy into their own Google Cloud project and pay Google directly for the resources they create.
Through Stripe or Flutterwave. Between them they accept card, bank transfer, USSD and mobile money. RAD never handles your card details: payment happens on the provider's hosted page, and credits are granted once it confirms.
The option for people with no Google Cloud account.
A Google Cloud project RAD creates and governs for you, in four tiers -- sandbox, development, production and lab -- each with its own policy set. Choose sandbox, development or production, in one of eight regions.
In the sandbox and lab tiers, external IPs, default networks, the VM serial port, service-account keys, public buckets and public Cloud SQL IPs are denied, and services limited to an allowlist. Development relaxes three, each with a compensating control.
Each managed project carries a monthly Google Cloud budget that alerts as spending approaches and exceeds it. A budget notifies, it does not block: it will not stop an API call, and raising it permits no additional spending.
RAD is designed to disable billing on the managed project until the balance is topped up, then re-enable it. The check runs every fifteen minutes and reverses only a suspension it applied itself, never an administrator's.
Mechanisms, described plainly.
You, and platform administrators. A trainer who provisioned a deployment for you as part of a cohort can see and tear down that deployment while you are on their roster — never anything you deployed yourself. Roles are resolved on the server from stored user records, never from what your browser sends.
No. Support access is scoped and temporary: an agent sees a customer's deployments only while a ticket assigned to them is open, and closing it ends the access — at once in the console, within five minutes on the API. Support is excluded from raw configuration values and outputs.
In RAD's own Cloud Storage bucket, not yours: the project and the resources are yours, the state file is ours, and there is no download in the product today. A record is deleted only after the retention period and a warning email, and RAD-managed projects are exempt from that sweep entirely.
No, and we do not claim one. The mechanisms: roles resolved server-side, secrets in Google Secret Manager, least-privilege service identities, org-policy guardrails on managed projects, and audit records on money-bearing actions. RAD holds no formal attestation.
Early access: this shipped in August 2026. The full picture for trainers.
A RAD administrator sets the trainer's roster, up to 30 participants. The trainer deploys from the ordinary form: one action provisions one deployment per participant, each into that participant's own RAD-managed project in the lab tier.
Each participant. The participant owns the project and the deployment, and credits are debited from their own account, never the trainer's, so every participant needs a funded account. Plan the course around that.
A trainer can see and tear down what they provisioned, and can never read a participant's secrets or outputs. Visibility comes from the roster and is re-checked on every request: strike a participant and the access ends.
The section a sceptic scrolls to first.
RAD is in beta. The catalogue and the deployment engine are built and running, and they configure cloud resources in a project you own, or a RAD-managed project you are billed for. Those parts are production ready; what is newer is named as early access.
Anything where using beta software is the risk: a workload needing a compliance attestation we do not hold, or a launch with no room for surprises. Test it today by deploying a single module into your own project and judging from that.
Because each one counts something that exists, and most are checkable without an account: the catalogue is browsable, and the labs and module guides sit behind no sign-in at all. None of them counts users, revenue or growth.
Three answers, then try it.
Sign up at radmodules.dev. You get 300 credits and are asked for no payment method. Pick a module, fill in the guided form and watch the build log; the module fee is shown before you confirm.
No. If you have one, RAD deploys into your project and you pay Google directly for the resources. If not, RAD can create and govern one, and the Google Cloud spend comes out of your credit balance.
Use the contact form; a person answers it. For technical depth, the documentation carries 345+ hands-on labs and 520+ module configuration guides, none of it behind a sign-in. Start with the resources page.