Proof, not promises
To make this a hard test, not a friendly demo, we ran the same complex application — a multi-tenant SaaS with a web frontend, API, Postgres primary + read replica, async workers, object storage, a CDN, auth, Stripe payments (PCI-DSS), per-tenant audit logging, and a 99.9% uptime target — nine times: at each of three experience levels across AWS, Azure, and GCP. Every figure below traces to a run artifact.
Results, all nine runs
| Experience | Cloud | Validator | Consistency | Lint | Cites | Cost | Max out | Energy |
|---|---|---|---|---|---|---|---|---|
| First deploy | AWS | PASS | PASS (0 dangling) | PASS | 8 | $0.80 | 5,773 | 43 Wh |
| First deploy | Azure | flagged | PASS | PASS | 10 | $0.56 | 5,306 | 31 Wh |
| First deploy | GCP | PASS | PASS | PASS | 14 | $0.71 | 3,400 | 39 Wh |
| Some experience | AWS | PASS | PASS | PASS | 5 | $0.83 | 6,579 | 43 Wh |
| Some experience | Azure | PASS | PASS | PASS | 13 | $0.47 | 4,380 | 27 Wh |
| Some experience | GCP | PASS | PASS | PASS | 12 | $0.52 | 3,813 | 29 Wh |
| I know my stack | AWS | PASS | PASS | PASS | 8 | $0.99 | 6,143 | 52 Wh |
| I know my stack | Azure | PASS | PASS | PASS | 13 | $0.53 | 5,325 | 29 Wh |
| I know my stack | GCP | PASS | PASS | PASS | 10 | $0.48 | 3,755 | 27 Wh |
The most important run is the one that flagged
The headline proof isn't the 8/9 that passed — it's the one that didn't. On the first-deploy / Azure run, the validator flagged, in plain language: manual read-replica failover as inadequate for a 99.9% SLA; public access to data stores not explicitly disabled; Terraform state in Blob Storage not confirmed encrypted/locked; and several citations not carefully matched to their claims. That is an independent check doing real work and reporting honestly — not rubber-stamping. We surface its findings rather than gate on them.
The platform, load-tested
Beyond the plans themselves, the pipeline is validated under real load: 20 full generations running concurrently against live models produced 0 throttling failures and no latency degradation (median ~117s, in line with a single run). The deployed path runs at a bounded worker concurrency with a queue that absorbs bursts with zero loss and nothing dropped, plus a daily cost breaker that stops runaway spend. Reliability we measured, not assumed.
Cloud-native per target, not a reskinned template
The same app, mapped to each cloud's own idiomatic services.
| Concern | AWS | Azure | GCP |
|---|---|---|---|
| Compute | ECS Fargate | App Service / Container Instances | Cloud Run |
| Database | RDS PostgreSQL | Azure DB for PostgreSQL | Cloud SQL |
| Object storage | S3 | Blob Storage | Cloud Storage |
| CDN / edge | CloudFront | Front Door / CDN | Cloud CDN |
| Async / queue | SQS | Service Bus | Pub/Sub + Cloud Tasks |
| Auth | Cognito | Entra ID | Identity Platform |
| Secrets | Secrets Manager | Key Vault | Secret Manager |
| Observability | CloudWatch | Azure Monitor | Cloud Logging / Monitoring |
vs. a general-purpose LLM chat
A general assistant is a broad, useful tool — but structurally different from a grounded, verified pipeline. Not a claim that a chatbot produces bad output; it's that a chatbot provides none of these guarantees.
| deplovox infra god | Generic LLM chat | |
|---|---|---|
| Grounding | The target cloud's own docs, retrieved per app | Training data — may be stale or blurred |
| Citations | Every factual claim links to a real doc URL | None you can verify |
| Validation | Automated QA + security checklist, shown ✓ / ✗ | None |
| Consistency | Deterministic zero-dangling-reference check on the IaC | None |
| Reproducibility | Per-run manifest (inputs, corpus, models, versions) | Not reproducible |
| IaC generation | Planned contract → bounded sections → assembled | One prompt, hope it fits |
What validation actually runs — precisely
In the request path, IaC gets real schema validation per format: CloudFormation with cfn-lint (schema and rule linting); Terraform with real `terraform validate` — the actual HashiCorp CLI with the aws / azurerm / google providers pinned to the versions the plan emits, run in a sandboxed container so it checks resource arguments against the real provider schemas, not just a parse. On BOTH, a deterministic zero-dangling-reference consistency check runs, and any validation errors are fed back into the per-section corrector and re-checked until they clear. On top of validation, the generated IaC is scanned offline in the same container with checkov (security & compliance policies — Terraform and CloudFormation) and, for Terraform, tflint (lint / best-practice, with the aws/azurerm/google rulesets); the findings are shown to you in full. Scanning is advisory — it surfaces issues, it does not block the plan or silently auto-fix them. What still does NOT run in the request path: `terraform plan` (it needs live cloud credentials and state). python-hcl2 stays as a fast pre-parse and the fail-open fallback, so a scanner or validator outage never blocks your plan.
A real cited excerpt
from a real runMulti-Tenant SaaS on AWS — Production Architecture
The system runs Next.js (frontend + API routes) on ECS Fargate behind an Application Load Balancer, with RDS PostgreSQL Multi-AZ (writer) plus a read replica for query offload. Background jobs are consumed from SQS by separate Fargate worker tasks, scaling independently of the web tier. CloudFront sits in front of both the Next.js app and S3 static assets; Cognito handles auth with one User Pool per tenant; all Stripe webhooks enter through the ALB and are processed inline or enqueued.
- RDS PostgreSQL 16, Multi-AZ instance for the 99.9% availability target [Source 1]
- Application Load Balancer with WAF rules for the OWASP top-10 and PCI scope [Source 8]
- Amazon Cognito User Pools for JWT auth with TOTP + SMS MFA available [Source 25]
What we don't claim
- Not "guaranteed to deploy." Grounded, cited, validated, and consistency-checked are necessary conditions for a good plan — not a promise that `terraform apply` or `cloudformation deploy` succeeds in your specific account, region, or quota.
- A citation verifies a FACT — that a service exists or supports a feature — not that the chosen service is the OPTIMAL fit for your workload. The architecture judgment is still yours to review.
- Terraform gets real `terraform validate` with providers, and the generated IaC is scanned with checkov + tflint, all in the request path. But `terraform plan` still doesn't run (it needs live cloud credentials and state), so validate-clean is not a guaranteed `apply`.
- Static scanning (checkov + tflint) surfaces security and best-practice issues — it does not guarantee a secure or deployable result, and we don't auto-fix every finding. Some flagged items are reasonable trade-offs for a starting-point plan; review them for your context.
- The validator is advisory: it flags gaps (see the failed Azure run on the proof page) rather than blocking the result.
- Energy and carbon figures are transparent estimates with their formula and sources shown — not measurements.
Every figure above traces to a specific run artifact — nothing here is a claim you can't check. See three runs up close on the showcase, or how the pipeline works on the trust page.