Tell us what you need — see it before anything is built.
No cloud jargon required. Explain what you need the way you'd explain it to a colleague.
Diagrams, cost, and compliance — computed from deterministic rules, not a guess — before you approve anything.
Terraform, Ansible, or Python. Your infrastructure, generated and applied on your say-so.
Your account keeps this project's design history and activity log separate from everyone else's.
Google Sign-In is not configured on this server — use email/password below.
Enter your business name above to enable this.
Google Sign-In is not configured on this server — use email/password below.
At least 8 characters.
What's your business name? This keeps your projects separate from everyone else's.
Describe it the way you'd explain it to a colleague — what it's for, who uses it, and anything you already know you need (e.g. "must stay private," "traffic is bursty"). No cloud jargon required. We'll turn this into a proposed design and ask you to confirm it before anything is built.
We already picked up what we could from what you told us — those are shown below for your reference. Everything else, just answer as best you can; if you're not sure, the default is a safe choice.
Add your own question or requirement if something isn't covered above — you'll answer it right here before we build the design.
Compared against the last version of this project you clicked "Approve" on — not just the last time you ran reqctl.
A rough monthly range for what you're about to approve, plus what the other ways of running it would have cost — so you can see the tradeoff, not just the price.
A fixed set of infrastructure-level controls checked against what will actually be built — not a certified SOC2/HIPAA/PCI assessment, and not a substitute for a real audit.
Every mandatory rule reqctl enforces traces back to a pillar of Google's own Cloud Architecture Framework — not an unreferenced internal opinion.
Informational only — doesn't change what's approved unless you do.
What this design does and doesn't cover if traffic grows or something fails — informational, same as the tech-stack suggestion above.
Who uses it, what it is, and how information flows — no technical cloud terms yet.
What will actually be built on Google Cloud, for your technical reviewer. Built by fixed, repeatable rules — not guesswork — so this always matches what gets deployed.
Optional: get a plain-language explanation of the design above.
Everything is created in your own Google Cloud project, billed to you.
The same generator reqctl deploy uses on the command line — nothing new here, just run from the browser. Generates and validates the actual Terraform/Ansible for this spec before anything else runs.
Checking whether the Terraform state bucket exists and the required
Google Cloud APIs are enabled on your project, against what was just
generated above. This runs gcloud on the machine running reqctl.
What Terraform would create or change. Nothing happens until you approve it below.
terraform apply for real, against your
actual Google Cloud project. This creates and can destroy real
billable resources. There is no undo button here —
reqctl does not currently generate a teardown for you.
Re-checks live Google Cloud against what was last applied here — if they differ (someone hand-edited a resource, something was deleted outside Terraform, etc.), that's drift. Only meaningful after at least one successful apply in this session.
Deletes everything this deploy screen created for this spec — only enabled after at least one successful apply in this session. Shows what would be destroyed before anything is deleted, same confirm-then-act discipline as Apply above.
Who did what, from where, and when — a local record only (see README "Auth & audit log"). Not a compliance control; a plain file anyone with access to this machine could edit.