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.
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 is checked per format: CloudFormation with cfn-lint (schema and rule linting); Terraform with python-hcl2 (syntax / parse validation). On BOTH, a deterministic zero-dangling-reference consistency check runs — every referenced resource and variable must resolve to something defined. What does NOT run in the request path: full `terraform validate` with providers, tflint, checkov, and `terraform plan`. Full `terraform validate` runs in our CI gate, not on your request. The checks are real but asymmetric — CloudFormation gets deeper schema linting than Terraform gets in-path — and we say so rather than imply parity.
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 is syntax- and consistency-checked in the request path, not fully `terraform validate`-d with providers (that runs in our CI gate). cfn-lint gives CloudFormation deeper schema linting in-path — an honest asymmetry, not parity.
- 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 how the pipeline works on the trust page.