reqctl

tell us what you need — see it before anything is built
1. Tell us about it
2. A few details
3. Review & approve
4. Deploy

What do you need?

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.

A few details

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.

Anything else?

Add your own question or requirement if something isn't covered above — you'll answer it right here before we build the design.

How confident are we?

Changes since you last approved this project

Compared against the last version of this project you clicked "Approve" on — not just the last time you ran reqctl.

What will this cost?

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.

Compliance checklist

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.

Standards this design follows

Every mandatory rule reqctl enforces traces back to a pillar of Google's own Cloud Architecture Framework — not an unreferenced internal opinion.

Your project, in plain terms

Who uses it, what it is, and how information flows — no technical cloud terms yet.

Overview
How it's kept secure and running

The technical design

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.

Overview
Detail (networking & addressing)

Why this design?

Optional: get a plain-language explanation of the design above.

Nothing has been built or deployed yet. This is a preview for you to approve.

Generate Terraform

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.

Before we deploy

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.

Desired state: the plan

What Terraform would create or change. Nothing happens until you approve it below.

Clicking Apply runs 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.

Desired vs. actual state

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.

Teardown

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.

Clicking Destroy deletes real cloud resources. There is no undo.

Activity log

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.