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.
Screened and scoped before it runs
Before any plan is generated, your description passes a safety gate — an Amazon Bedrock guardrail that blocks harmful input, plus a check that keeps infra god scoped to real cloud-deployment requests. Defense-in-depth, on top of the models' own safety training.
Right-sized to your scale and budget
The design matches what you asked for: a small app gets a lean, serverless plan; a mission-critical one gets the redundant, multi-AZ stack. Every plan carries a monthly cost estimate and a cheaper alternative — and if the honest cost is over your budget, it says so plainly rather than pretending it fits.
Least-privilege and secret-safe by default
The generated infrastructure code is scoped to least privilege — no blanket Action or Resource wildcards — and secrets are referenced from a managed secret store, never inlined as plaintext. It meets that bar before you see it, not as a to-do left for later.
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.
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 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.
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.