A solution is several applications, pre-composed, deployed into one Google Cloud project as a single dependency-ordered unit. The catalogue holds more than 60.
Most deployment tools install one application. RAD's solutions install a working set into the same project on one confirmation, several at a time, and a member waits only for the member whose output it needs.
Every member is an ordinary RAD module, landing in a Google Cloud project you own as plain Terraform. Each member's Terraform state is held in RAD's own Cloud Storage bucket, not in your project.
Six applications a business of five to fifty people needs in order to trade and get paid. One form, one confirmation, six deployments into one project.
The system of record for customers, quotes, orders and the chart of accounts. Everything else in the suite sits around it.
Raises and chases invoices against the customers and orders held in the ERP core.
Time recorded against customers and projects, for the work that is billed by the hour rather than by the deliverable.
Contracts and order forms signed without a per-envelope subscription. Documenso is the listed alternative if you prefer it.
The document store behind all of the above, in the same project rather than in someone else's consumer drive.
Listed last because it links to the other five. Nothing wires this connection for you: you point it at their addresses once they are running.
Solutions carry named alternatives where a substitute exists. Dolibarr can be swapped for Odoo or EspoCRM here, leaving the rest of the bundle unchanged.
Two things hold a member back: the shared foundation, if the project and its shared services are being created as part of this deployment, and a producer whose Terraform outputs the member needs. Everything else starts as soon as you confirm.
The whole solution is written at once, with credits reserved as a single sum. A member that must wait names the deployments it needs; everything else is queued immediately.
Not for a stage, and not for the member in front of it. It is released once every deployment it names has succeeded. If one fails, that member is cancelled and the rest carry on.
Members with nothing to wait for are provisioned in parallel, up to three at once, rather than one after another, so a six-application solution is not six builds run back to back.
The credit cost of every member is reserved as a single sum before the first build starts, so a solution is never left standing part-way through because the credit balance ran out.
Producer-and-consumer pairs are wired by the platform. In other solutions, every connection between members is a step you carry out after the deployment finishes.
Where a pair is wired, the producer publishes real Terraform outputs: a service URL, a cluster-internal address, an API endpoint. When it finishes, those values are copied into the consumer's configuration before it builds, as an environment variable or a typed Terraform variable.
The headless CMS's service URL is written into the search service's environment when Directus finishes, so search starts up knowing where the content lives.
Elasticsearch's connection details are written into RAGFlow's and Zammad's configuration when Elasticsearch finishes. Both use it as their search back end.
The model runtime and the gateway in front of it both hand their endpoints to the chat interface, so it has models to talk to on first load.
The analytics database's cluster-internal address, database, user and password secret are written into Plausible's configuration. Plausible checks at plan time that it has a ClickHouse to write to, so this solution cannot be applied without the wiring.
The Matrix homeserver's address goes into the client, which is otherwise a web app pointed at nothing.
The CI server is given the address of the source host it builds from. Registering the OAuth application on the Gitea side is still yours to do, and the solution says so in its post-deployment notes.
Everywhere else, connecting the members is your job. The members of a solution arrive in one project, on one shared foundation, with one credit reservation and in an order that respects what depends on what. They do not arrive integrated.
Some solutions carry written post-deployment notes for the work that remains: connecting Nextcloud to ONLYOFFICE, registering the Gitea OAuth application Woodpecker needs, adding VictoriaMetrics and Loki to Grafana as data sources. The rest leave it to each application's own setup.
Where this sits in the beta. Automatic wiring is one of the newer parts of RAD, so we describe it as designed to connect these pairs. After a solution finishes, check the values in each member's configuration before relying on them.
Destroying an estate in the wrong order is how you end up with failed teardowns and resources nobody can account for.
Deleting a solution asks every member to go. A prerequisite is not torn down when its reference count reaches zero: that only means its dependents were asked to leave. Its teardown is parked until all of them are terminal.
A dependent whose own destroy fails still releases the thing above it. Waiting for success would strand the prerequisite in a deleting state indefinitely, instead of finishing the teardown and showing you the member that failed.
Before refusing to destroy something because other deployments depend on it, RAD resolves each reference and blocks only on those that still exist, then rewrites the list. A stale reference does not become a permanent block.
60+ solutions, grouped by the job they do rather than by the technology inside them. Two named examples from each.
| Category | Example solutions | Applications inside them |
|---|---|---|
| Business Operations & Back Office | Small Business Suite · Integrated ERP Platform | Dolibarr, Invoice Ninja, Kimai, Odoo, Metabase, OnlyOffice |
| Sales, Marketing & Customer Engagement | CRM & Sales Operations · Marketing Automation Suite | Twenty, Cal.com, Listmonk, Mautic, Matomo, n8n |
| Web Presence, Content & Commerce | Headless Content Platform · E-commerce Storefront | Directus, Meilisearch, Umami, Medusa, Payload |
| Digital Workplace & Collaboration | Team Workspace · Secure Team Communications | Nextcloud, OnlyOffice, Mattermost, Synapse, Element, Vaultwarden |
| Developer Platform & DevOps | Source Control & CI/CD · Observability & On-call | Gitea, Woodpecker, Grafana, Loki, Uptime Kuma, GlitchTip |
| Data, Analytics & BI | Analytics Warehouse · Self-service BI | ClickHouse, Superset, Metabase, NocoDB, CloudBeaver |
| AI & Automation | Private AI Assistant · Enterprise RAG & Document Intelligence | Ollama, LiteLLM, OpenWebUI, Qdrant, Elasticsearch, RAGFlow |
| Identity, Security & Zero Trust | SSO Foundation · Zero-trust Network & DNS | Keycloak, Passbolt, Infisical, Headscale, AdGuard Home |
| IT Operations & Service Management | IT Service Desk · Monitoring & NOC | Zammad, Snipe-IT, BookStack, Uptime Kuma, Netdata, Gatus |
| Education & Training | Learning Management Platform · Developer Training Lab | Moodle, Nextcloud, Element, code-server, Gitea |
| Industry & Sector Solutions | Clinic & Practice Management · NGO & Nonprofit Operations | OpenEMR, Cal.com, Paperless, Dolibarr, LimeSurvey |
| Personal Cloud, Media & Lifestyle | Personal Cloud · Digital Library | Nextcloud, Immich, Vaultwarden, Calibre-Web, Komga, Audiobookshelf |
All are seeded and selectable. See the full module catalogue — 350+ deployment options across 190+ applications and platform modules.
The same module fees as deploying each application on its own, less a bundle discount that grows with the size of the solution.
Every member's fee is shown in the confirmation screen, line by line, with the discount applied and the resulting balance, before anything is provisioned. A build that fails carries no module fee.
Build cost is metered from how long provisioning actually ran, and most modules build in well under half an hour.
The same estate, once per participant, from the same form.
A trainer whose roster an administrator has set, up to 30 participants, can provision a multi-application solution as a capstone exercise. Each participant gets their own real Google Cloud project, in the lab tier's own folder, with the tightest guardrail set RAD applies.
The participant owns the project and the deployment, and credits are debited from each participant's own funded account. Striking a name from the roster ends the trainer's access to that participant's deployments; emptying it closes the cohort at end of term.
Cohort provisioning shipped in August 2026 and is the newest thing on the platform. We are looking for pilot partners.
Pick a solution, answer the questions that differ between one installation and the next, and watch it build into a project you own.
Google Cloud only. Every module is Terraform. RAD is a way to deploy a governed estate without writing the infrastructure code for it.