RAD is in beta. The platform, catalogue and documentation are built and running — we are early, and we would rather you heard that from us.
Pick from 354 ready-made deployment options, answer the questions that genuinely differ between one installation and the next, and RAD provisions it as plain Terraform into a Google Cloud project you control — or into a governed project RAD creates for you if you do not have one.
Writing the Terraform. Wiring the service accounts. Setting the org policy. Connecting one application to the next so it actually starts. It is the same labour on every project, and most organisations pay for it more than once — six squads each inventing the same landing zone, or one founder spending a month of scarce early-stage funding on infrastructure no investor will ever ask about. RAD turns that labour into a form, and it does it from a catalogue you can count.
Catalogue, solutions and regions counted 2026-08-17. Every figure on this site is something we counted on a stated date, not something we projected.
Four steps, and nothing hidden between them.
Pick from the catalogue: 354 deployment options covering 190 applications and platform modules. Most applications ship in both a Cloud Run and a GKE variant, so the choice you are making is an operating-model choice rather than a compromise.
Basic mode asks only for the variables that are genuinely mandatory. Advanced mode exposes the full set. The module fee — between 40 and 300 credits depending on complexity, and nothing at all for nine of the 354 options — is shown before you confirm, not after.
RAD runs the provisioning job and streams the build logs while it runs. If something fails, you read the same output an engineer would read, at the moment it happens.
When it finishes you get the Terraform outputs — addresses, endpoints, connection details. Reopen the same pre-filled form later to change something, or tear the deployment down from it.
What lands is ordinary Terraform, and the project and the resources are yours. The Terraform state is not: every deployment's backend points at RAD's own Cloud Storage bucket, in RAD's project, and there is no state download in the product today. RAD is still not in the request path — if you never sign in again, the deployed resources keep running exactly as they are — but the state that tracks them is held by us, and that is the honest answer to the lock-in question rather than a comfortable one. The rest of the boundary is worth stating just as early: RAD is Google Cloud only, and the module contract is Terraform. If that is not your stack, RAD is not your tool.
Held by us, and not held forever: after the retention period, RAD deletes its record of a deployment and the state with it — but only for an account that has gone quiet in the platform and holds no purchased credits, and only after a warning email that we have recorded as sent — if the warning never went out, the record is kept instead. Buying credits, or signing in, exempts the account. The deletion removes RAD's bookkeeping, not your resources; they carry on running in your project either way.
Most deployment tools install one thing. RAD's catalogue also carries 62 pre-composed solutions, defining 291 member deployments drawn from 151 distinct applications, across 12 categories.
Take the small-business suite. It is six applications — Dolibarr, InvoiceNinja, Kimai, Docuseal, Nextcloud and Homepage — deployed into one project on one confirmation. You answer the union of their mandatory questions once, RAD reserves the credits for the whole thing as a single sum, and the members provision three at a time.
Members that depend on nothing are queued the moment you confirm and provision three at a time. A member that consumes another member's Terraform outputs waits for that specific deployment to finish — not for a whole batch 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. Every other connection between members is a step you carry out yourself afterwards, and automatic wiring is a beta capability we describe as designed rather than proven.
Teardown walks the same graph backwards, because a shared project has to outlive the things living inside it. Getting that ordering wrong is what turns a clean delete into a set of orphaned failures.
The same catalogue and the same engine serve both. Which one you pick is the whole product.
RAD is subject to your organisation's policies like any other principal and cannot widen them. Region narrowing does not apply here — you keep every region Google offers. The infrastructure it creates is standard Terraform, legible to anyone you hand it to. The state file is the exception to "it is all yours": it lives in RAD's Cloud Storage, not in your project, and the product has no way to hand it over today.
For anyone who does not have a Google Cloud account, or does not want to use theirs for this. The four tiers — sandbox, development, production and lab — each live in their own Google Cloud folder with their own policy set, so one tier's rules cannot drift into another's. The lab tier is available to trainers and administrators only; the other three are self-selectable.
In the sandbox and lab tiers: external IP addresses are denied, default networks are suppressed, serial port access is disabled, service-account key creation and upload are blocked, public buckets are prevented, public Cloud SQL IP addresses are refused, resource locations are restricted, and the set of Google Cloud services that can be enabled is restricted to an allowlist. The development tier keeps the same credential-hygiene floors and relaxes three of those rules, each with a compensating control — an external IP requires OS Login and a Shielded VM, a public bucket requires uniform bucket-level access, a public database IP requires authorised networks. The production tier carries development's resource ceilings, not a looser set: 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, and no GPUs or Vertex AI accelerators at all. Each of those is raisable per project on request. These ceilings apply to RAD-managed projects only — in your own project, your quotas are your own.
Every RAD-managed project also carries a monthly Google Cloud spend alert, which raises a notification as spend approaches and exceeds its figure. Be clear about what that is: it notifies, it does not block an API call. Enforcement is a separate mechanism, and we describe it separately on the pricing page rather than letting an alert stand in for it.
The eight regions are us-central1, europe-north2, northamerica-south1, me-west1, africa-south1, asia-east1, australia-southeast2 and southamerica-west1 — one in each geography, each selected as the cheapest available region there, measured from Google's Cloud Billing Catalog API. africa-south1 is the only Google Cloud region on the African continent. Seven of the 354 modules cannot go into a RAD-managed project; they are named on the modules page.
RAD is deliberately not the cheapest way to run one small application. It is for people who deploy the same shape of infrastructure repeatedly, or who need more of it than they want to hand-write. If that is not you, the honest answer is that you do not need us.
The same infrastructure authored independently by every squad, a security review that never converges, and no single answer to what is deployed, by whom, at what cost. One reviewed catalogue, deployed into projects you already govern, as ordinary Terraform.
Cloud credits reduce the bill, not the work. Deploy the estate you actually need as one unit instead of twelve separate afternoons, into your own Google Cloud project — and hand a diligence reviewer ordinary Terraform rather than a proprietary abstraction.
Thirty real Google Cloud environments on Tuesday morning and none of them on Friday afternoon. A trainer provisions a cohort in one action into the lab tier — a governed project per participant, in its own Google Cloud folder, available to trainers and administrators only.
Publish your own Terraform modules from your own repository into the same catalogue and deploy them for clients through one interface — or have your software deployed as you publish it, with no fork, no repackage and no licence change.
Cohort provisioning for trainers shipped in August 2026 and is early access. We say so on the page that sells it, too.
Not a promise of docs to come. These are published pages you can read before you sign up for anything, counted 2026-08-17.
Each one walks a deployment end to end and finishes with something running, rather than with a diagram of something that could run.
One for each of the 346 application options, plus 177 shared foundation guides they build on. Each lists the variables the deployment form will ask you about and what each of them does.
Aligned to seven Google Cloud certification tracks: ACE, PCA, PCD, PCDE, PCNE, PDE and PSE.
300 credits when you sign up, and 100 credits each month after that, with no payment method required. Free users deploy into their own Google Cloud project and pay Google directly for what runs there.
When you do want to pay, RAD takes payment through Stripe and Flutterwave — card, bank transfer, USSD and mobile money — and never handles your card details itself. Credits are granted only after the provider confirms the payment.
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.