Why you can trust these plans
An AI deployment plan is only useful if you can check it. deplovox grounds every plan in the target cloud's own documentation, cites it, validates it against an explicit checklist, deterministically checks the infrastructure code for internal consistency, and makes each run reproducible. We don't claim a plan is guaranteed to deploy — accounts, quotas, and versions differ — we claim what we can verify.
Grounded in the cloud's own docs
Every plan is built from the target cloud's own documentation. infra god retrieves the relevant pages for your app and grounds the architecture in them — so the services and limits reflect the provider's own material, not blurred training data.
Cited, so you can check it
Factual claims carry a [Source N] marker that maps to a real documentation URL on the provider's own site (for example, docs.aws.amazon.com). The result's Sources panel lists every one, and they open in a new tab.
Validated against an explicit checklist
Before you see a plan, an automated review runs a quality checklist on the architecture and a security checklist on the infrastructure code — Well-Architected-style: encryption, least-privilege access, no publicly exposed data stores. The results show as a visible ✓ / ✗ list, pass or fail.
Consistency-checked — zero dangling references
After the infrastructure code is assembled, a deterministic check — code, not another model — verifies that every referenced resource and variable is actually defined. Zero dangling references. A linter (cfn-lint for CloudFormation, an HCL check for Terraform) runs on top.
Reproducible via a per-run manifest
Every run ships a downloadable manifest: your exact inputs, the documentation-corpus version, the model IDs behind each stage, the pinned IaC provider versions, a timestamp, and the job ID — so a result can be traced and regenerated, not just trusted.
Generated section by section, not one blob
The infrastructure code isn't one hopeful generation. A plan assigns every name once, then bounded sections — networking, compute, data, identity — are generated against that contract and assembled deterministically, then consistency-checked.
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.
deplovox vs. a generic LLM chat
A chatbot can also describe an architecture. The difference is whether you can verify it.
| 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 |
Example output
from a real runA real, unedited excerpt from an actual infra god run for the multi-tenant SaaS described above. Every [Source N]links to AWS's own documentation.
Multi-Tenant SaaS on AWS — Production Architecture
Architecture Overview
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.
Cited decisions
- 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]
Sources
Straight answers
Can I trust an AI-generated cloud deployment plan?
You can trust what is verifiable. deplovox grounds every plan in the target cloud's own documentation and cites it, runs an explicit validation checklist, deterministically checks the infrastructure code for internal consistency (zero dangling references), and ships a per-run manifest so the result is reproducible. It does not claim a plan is guaranteed to deploy — accounts, quotas, and versions differ — but every claim it makes is checkable.
How does deplovox avoid hallucinating cloud services?
It retrieves relevant pages from the target cloud's own documentation and grounds the architecture in them, citing each factual claim with a [Source N] link to the doc. An automated validation step then checks the plan against a quality and security checklist before you see it.
Are the citations real?
Yes. Each [Source N] marker maps to a real documentation URL on the cloud provider's own site — for example docs.aws.amazon.com, learn.microsoft.com, or cloud.google.com — and every one is listed in the result's Sources panel.
Is the infrastructure code checked before I get it?
Yes. Once assembled, a deterministic check verifies every referenced resource and variable is defined — zero dangling references — and a linter (cfn-lint or an HCL check) runs. The security of the code is reviewed against a Well-Architected-style checklist, shown pass or fail.
Can I reproduce a deployment plan later?
Every run includes a downloadable manifest with your inputs, the documentation-corpus version, the model IDs behind each stage, the pinned IaC provider versions, a timestamp, and the job ID — enough to trace and regenerate the result.
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.
See it on your own app
Describe your app and read the plan — with its citations, validation checklist, and downloadable manifest — in a couple of minutes.