354 deployment options covering 190 applications and platform modules, counted 2026-08-17. Each one is a Terraform module RAD writes and maintains, with a guided form, a written configuration guide, a price shown before you deploy, and a destination that is a Google Cloud project you own.
Two numbers, because they mean different things. 354 is the number of ways you can deploy something; 190 is the number of distinct applications and platform modules behind them.
A Terraform module that RAD authors and maintains, with its input variables exposed as a form. Deploying it runs Terraform against a Google Cloud project — yours, or one RAD creates and governs — and leaves you with ordinary Terraform-managed infrastructure in that project. The contract is Terraform and the target is Google Cloud; there is no proprietary runtime in between. The Terraform state is held in RAD's own Cloud Storage bucket rather than yours.
Most applications ship in both a Cloud Run and a GKE variant, so the same application appears twice under two different operating models. Some ship in one variant only — Elasticsearch and Immich are GKE, because what they need from the platform does not fold neatly into a request-driven service. The 190 also counts entries that are not applications in their own right: RAD's project and shared-services foundations, the Cloud Run and GKE deployment engines the application modules build on, a reference sample, and the fleet-registration, service-mesh, reference-architecture and migration modules RAD publishes itself. Most of those stand up their own cluster or private cloud; Migration_Center is the one that only assesses an estate you already run.
Cloud Run suits request-driven services you would rather not run a cluster for. GKE suits anything wanting persistent volumes, long-lived processes, or components that talk to each other inside a cluster. Same application, one shared application guide plus a guide per operating model, different bill and different day-two work. Pick the one that matches how you intend to operate it.
62 pre-composed solutions in the catalogue deploy several of these modules as one dependency-ordered unit, drawing on 151 of the 190 applications and platform modules. If you want an estate rather than an application, start there instead.
The same twelve used to organise the 62 solutions. A handful of named applications is given under each — they are examples, not the full contents, and the catalogue itself is searchable inside the product.
Running the company itself: ERP, CRM and document signature. Includes Odoo, EspoCRM and Documenso.
Reaching people and booking their time, on analytics you host yourself. Includes Matomo and Cal.com.
Publishing and headless content, from a blog to an API-first content back end. Includes Ghost, Strapi and Directus.
Files, chat, documents and knowledge for a team that would rather not rent them. Includes Nextcloud, Mattermost, Outline and Element.
Source hosting, pipelines, workflow orchestration and internal tooling. Includes Gitea, Woodpecker, Temporal and Appsmith.
Dashboards, exploration, search and the back ends underneath them. Includes Metabase, Superset, Grafana, Elasticsearch and Supabase.
Model serving, retrieval and workflow automation you run in your own project. Includes Ollama, LiteLLM, OpenWebUI, RAGFlow and n8n.
Single sign-on and identity brokering in front of everything else you deploy. Includes Keycloak.
Service desk, asset tracking and availability monitoring. Includes Zammad, Snipe-IT and Uptime Kuma.
Course delivery and the documentation around it. Includes Moodle, BookStack and Wiki.js.
Applications written for one sector rather than for everybody. Includes OpenEMR and Cyclos.
Photos, media libraries and personal archives kept in your own storage. Includes Immich, Jellyfin and PhotoPrism.
Twelve categories, 354 deployment options, 190 applications and platform modules — counted 2026-08-17. Deliberately not totalled by category here: the catalogue is the authority on what sits where, and a number on this page would drift the week after it was written.
The same six things, whichever of the 354 entries you pick.
Basic mode asks only for the variables the module marks mandatory. Advanced mode exposes the full variable set, with the module's own defaults and its own validation.
The confirmation screen lists the Google Cloud services the module will create and the credits it will charge, before anything is provisioned.
Terraform runs as a provisioning job and its output streams into the console. When something fails you read the reason rather than open a ticket about it.
URLs, connection details and generated identifiers are published against the deployment. The Terraform state is not published to you: it is written to RAD's own Cloud Storage bucket, in RAD's project. The resources and the project are yours; the state file is held by RAD.
Reopen the form pre-filled with what you deployed, change a value and re-apply. Terraform plans the difference instead of rebuilding.
Delete destroys what the module created, in dependency order. Purge removes RAD's record and leaves your infrastructure running.
Two components, both visible. Credits are the unit; the pricing page explains how you buy them.
Where a module sits in that range depends on how much it provisions and how much of the surrounding platform it has to configure. Nine of the 354 options carry no module fee at all: the module that creates a RAD-managed project, and the eight migration, service-mesh and reference-architecture modules RAD publishes itself. Whatever the fee is, it appears on the confirmation screen before you deploy — you never find out afterwards.
Charged from how long provisioning actually ran, at a per-hour credit rate published in the product. A module that finishes quickly costs less to build than one that does not, because that is what you used.
More than nine in ten finish inside 30, measured across recorded deployments to 2026-08-17. It is a spread on purpose: a module that creates a Kubernetes cluster sits at the slow end, one that publishes a container near the front. We publish the spread rather than an average, because an average would flatter the slow end.
Credits pay RAD for the deployment. When you deploy into your own Google Cloud project, Google bills you directly for what runs, at Google's prices — RAD is not in that path. When RAD creates and manages the project instead, that project carries a monthly Google Cloud budget, which raises alerts as spend approaches and passes its figure and does not block an API call. The mechanism that can actually interrupt a project is a separate one: RAD is designed to suspend Google Cloud billing on a managed project if your purchased credit balance goes negative, and to restore it once you top up.
Seven cannot, and it is better to name them than to let you find out at the confirmation screen. The reason is the same in every case: each one switches on a Google Cloud service that the RAD-managed tier's organisation policy allowlist denies, so the apply would stop with RESOURCE_USAGE_RESTRICTION_VIOLATED — sometimes part-way through, after resources already exist. They deploy normally into a Google Cloud project you already control, because that project is bound by your organisation's policies rather than RAD's.
Creates an AKS cluster in Azure and registers it with a Google Cloud fleet, so it is managed alongside native GKE clusters. It enables seven Google Cloud services the tier allowlist denies, among them gkemulticloud and connectgateway.
The same, for an Amazon EKS cluster it creates in AWS. It enables the same seven denied services.
A reference microservices banking application on a GKE cluster it provisions, with Cloud Service Mesh and fleet registration. It enables nine denied services, among them mesh, meshconfig and containersecurity.
The same reference application spread across several GKE clusters in several regions, with cross-cluster ingress and services. It enables fifteen denied services, among them multiclusteringress and multiclusterservicediscovery.
Provisions a Google Cloud VMware Engine private cloud with its own network peering and management plane. It enables vmwareengine and vmmigration, neither of which any RAD-managed tier allows.
A Google Cloud Migration Center assessment environment, for inventorying and rightsizing an existing estate. It enables migrationcenter, which no RAD-managed tier allows.
Google Cloud Migrate to Containers, for replatforming existing virtual-machine workloads onto a GKE cluster it provisions. It enables containerregistry, which is absent from the sandbox and development allowlists.
Counted 2026-08-17. Published, indexable, and readable without an account.
One for each of the 346 application options, plus 177 shared foundation guides those options build on. Each lists the variables the form will ask about, what each one does and what happens if you leave it as it is.
One per application option: step-by-step walkthroughs that end in a working deployment rather than a diagram. You can read one to the end before signing up for anything.
Aligned to seven Google Cloud certification tracks: ACE, PCA, PCD, PCDE, PCNE, PDE and PSE.
Those counts cover the 346 application options. The eight modules RAD publishes itself — AKS_GKE, EKS_GKE, Istio_GKE, Bank_GKE, MC_Bank_GKE, Container_Migration, Migration_Center and VMware_Engine — are documented differently: a configuration guide and a lab each, in the public repository they are published from rather than on the documentation site.
The catalogue in the product is the authoritative version, and it is searchable by application name. RAD is in beta; signing up gives you 300 credits and does not ask for a payment method. Google Cloud only, Terraform throughout — if that is not your target, this is the honest place to stop reading.
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.