CloudEntail Docs

Introduction

CloudEntail turns infrastructure-as-code into a conversational, guarded workflow. Describe what you need in plain language, and CloudEntail generates Terraform (or imports what you already have), checks it against policy, prices it, and walks it through plan → apply with the same safety a careful platform team would insist on by hand.

It is built for teams who are already running Terraform and want platform-grade guardrails — drift detection, destroy approval, plan gating, cost visibility — without hiring a dedicated SRE to build and maintain that tooling themselves.

How CloudEntail works

Generate or Import. Start from a prompt ("give me a t3.micro EC2 instance behind a security group allowing SSH from my office IP") or import existing cloud resources by ID. Either way, you end up with a real Terraform stack CloudEntail understands and manages going forward.

Guardrails check everything before it runs. Generated and imported code is scanned for insecure defaults, code-execution primitives (provisioner, data "external", unapproved provider sources), and policy violations before you're ever offered a Plan button.

Plan, then Apply — never blind. Every apply is bound to a specific, recent plan. If the code changes after planning, or the plan would destroy something you didn't approve, the apply is refused server-side — not just hidden behind a UI checkbox.

Environments are separate, promotion is explicit. A stack in dev and the same stack in prod have independent state. Promoting code from one environment to the next copies it forward for review; it never auto-applies.

Drift is detected, not assumed. A scheduled scan compares live cloud state against your stack's applied baseline and reports what changed outside Terraform — a console edit, a manual kubectl apply, anything.

Destruction requires approval. Any operation that would destroy or replace a resource — whether from an explicit destroy request or an apply that turns out to be destructive — is blocked until an admin approves it, with a mandatory reason attached to the request.

Core principles

• The guardrail is server-side, not a UI courtesy. Confirmation checkboxes reflect the actual authorization check; they don't grant it. A client can't talk its way past a destroy approval by setting a flag.
• Nothing destructive happens by accident. Renaming a resource label, dropping an import block, or promoting code between environments can each turn an "update" into a silent destroy-and-recreate. CloudEntail checks for exactly this shape of mistake before it reaches Terraform.
• Your infrastructure runs in your cloud account. CloudEntail holds per-tenant credentials and state (encrypted, KMS-backed); it does not proxy your workloads or lock you into a DSL — it generates and manages standard Terraform.
• Multi-cloud by design. AWS, GCP, and Azure are first-class; shared dependencies (a VPC, a subnet) are referenced by ID rather than re-created when you import or promote.
• Human-in-the-loop where it matters. Generation and planning are fast and automatic. Destruction and production promotion are not — they wait for a person.

Getting Started

1. Sign in

CloudEntail uses Google or Microsoft SSO only — there is no manual username/password login. Your organization is derived from your email domain:

• The first person to sign in from a company domain creates the organization and becomes its owner.
• Anyone else signing in with the same domain sends a join request, which an owner or admin must approve before they can see any infrastructure.
• Personal email domains (Gmail, Outlook, etc.) each get their own private organization — two people with personal addresses never land in the same tenant.

The owner can transfer ownership to another member of the same organization at any time.

2. Connect a cloud provider

Add credentials for AWS, GCP, or Azure under Settings → Cloud credentials. Credentials are encrypted per-tenant and scoped to your organization only.

3. Connect an AI provider

Before you can generate anything, add an API key for at least one supported model under Settings → AI provider:

Paste your provider's API key and CloudEntail validates it with a live test call before saving — you'll know immediately if the key is invalid rather than discovering it on your first generation. Only your key's last few characters are ever shown again in the UI; the full key is never displayed after saving.

You can switch providers or models at any time, and different team members can use different providers if your organization allows it.

4. Generate your first stack

Go to Prompt, describe the infrastructure you want, and submit. The generated code appears in Output, along with:

• A cost estimate for what you're about to create
• Any guardrail findings (security, compliance) that need review
• Plan and Apply buttons — Apply is disabled until a matching Plan has run

Review the plan output, confirm, and apply. If the stack has a name and region, its state is now tracked and it appears under Environments.

5. Import existing infrastructure

If you already have resources running outside Terraform, use Import Infra:

1. Choose a cloud, region, and a stack name
2. Provide the resource IDs to import (instance IDs, security group IDs, etc. — types are auto-inferred)
3. Choose the environment this stack belongs to
4. Optionally open a GitHub PR with the generated code

CloudEntail runs terraform import, reads the real state back, and generates HCL deterministically from what Terraform actually reports — filtered through the provider's own schema, so only attributes that are legitimately configurable are written (not the dozens of computed, read-only fields state files carry). Shared dependencies your stack doesn't own (a VPC it sits in, a subnet) are emitted as data references, not managed resources.

If you navigate away mid-import, reopening the panel reattaches to the same job in progress — nothing is lost.

6. Set up drift detection

Once a stack is applied, enroll it in drift scanning from its workspace settings. CloudEntail scans on a schedule and reports anything that changed outside Terraform, with the specific resources and attributes that differ. Auto-remediation can be enabled per workspace if you want drift corrected automatically rather than just reported.

7. Promote across environments

Under Environments, each stack shows its status per environment (dev → staging → uat → prod, or however you've configured the pipeline). Promote copies the applied code from one environment to the next for review — you then Plan and Apply it separately in the target environment. Nothing is auto-applied on promotion.

8. Bring your own encryption key (Enterprise)

Note: this feature is available on the Enterprise plan only.

On other plans, your credentials and state are still encrypted at rest using a dedicated CloudEntail-managed key per tenant — BYOK adds full customer control over that key, it does not change whether encryption happens.

By default, CloudEntail encrypts stored credentials and sensitive configuration with a key it manages on your behalf. Enterprise organizations can instead supply their own AWS KMS key, so CloudEntail never holds the only copy of your encryption key and you can revoke access by disabling the key on your side at any time.

To connect a customer-managed key, go to Settings → Encryption (BYOK) and provide:

Your key's IAM policy must grant CloudEntail's calling identity (or the role it assumes, if you're using cross-account access) permission to encrypt and decrypt using the key. After saving, CloudEntail runs a round-trip verification against the key before treating it as active — if that check fails, encryption falls back to the previous key rather than silently failing.

If your organization is not on the Enterprise plan, this page will show which plan is required rather than letting the key be saved — nothing is silently ignored.

Core Concepts

Stack — a named piece of infrastructure with its own Terraform state, scoped to a specific cloud, region, and environment. The same stack name in two environments is two independent workspaces with two independent state files.

Workspace — the internal record backing a stack+environment: its state location, applied code, last-applied timestamp, and drift baseline.

Plan gate — the server-side check that runs before any apply. It verifies the plan is recent, matches the code being applied, and — if the plan would destroy or replace anything — that the destruction was explicitly approved. An apply that fails this check is refused before Terraform ever runs.

Destroy request — the only path to intentionally destroying applied infrastructure. Requires a reason (minimum 10 characters, shown to the approver) and admin approval before any terraform destroy executes. A stack that was never applied is archived instead of destroyed, since there's nothing in the cloud to remove.

Guardrails — policy checks run against generated and imported code: baseline security rules for Terraform and Kubernetes, a secret scanner, a module source allowlist, and a block on code-execution primitives (provisioner, data "external"/"http", unapproved provider sources) that could otherwise turn a generation into remote code execution.

Drift — any difference between your stack's applied configuration and what's actually running in the cloud. Detected via a state-hash check first, confirmed with a full terraform plan before being reported, so routine state bookkeeping isn't mistaken for a real out-of-band change.

Feature Reference

AI Chat — Prompt & Output

Describe infrastructure in natural language; CloudEntail generates Terraform (or Kubernetes manifests, Ansible, Helm, depending on what you're targeting). The Output panel shows the generated code, a live cost estimate, guardrail findings, and the Plan/Apply flow. Generated code can be pushed to GitHub as a draft PR, either automatically (if auto-push is enabled) or on demand.

Modify Stack

Edit an already-applied stack by describing the change you want. The generator is instructed — and separately, mechanically checked — never to rename or drop an existing resource's label, because a renamed label is what makes Terraform destroy and recreate a resource rather than update it in place. If a generated edit would do that, it's rejected before you ever see a plan.

Import Infra

Bring existing cloud resources under Terraform management. See Getting Started → Import existing infrastructure above for the full flow.

Environments

View and promote stacks across your environment pipeline. Each environment cell shows whether a stack is not created, promoted-but-not-applied, or applied, with Plan/ Apply actions once code has landed. Promoted code is automatically stripped of import blocks, since those carry the source environment's concrete resource IDs — left in, they'd make the target environment adopt (and potentially destroy) the source's live resources.

Ask CloudEntail, available in the promote code editor, answers specific technical questions in place — for example, the correct data "aws_ami" filter for Ubuntu versus Amazon Linux, which differ completely. It returns a snippet for you to review and paste; it never rewrites your stack directly, so the promotion guardrails stay the only authority over what actually gets applied.

Kubernetes

Register clusters (EKS, GKE, AKS, or any reachable cluster) and deploy manifests through the same generate → guardrail → apply flow as Terraform. Kubernetes-specific guardrails block privileged containers, host namespace sharing (hostPath, hostNetwork, hostPID, hostIPC), containers running as root, and — the Kubernetes equivalent of a Terraform local-exec — any manifest binding a service account to cluster-admin.

FinOps

Cost visibility synced from your cloud billing data: spend over time, by service, by tag, rightsizing recommendations, budgets and alerts, and tag policy enforcement. Deploy-impact estimates on the Apply panel show the actual monthly delta a plan would cause — additions increase projected spend, destructions decrease it, and a plan with no changes correctly shows no cost impact at all.

LLM Usage & Governance

Usage dashboards (tokens, cost, by task, by model) plus enforceable limits: daily/monthly token and cost caps, allowed models, and blocked task types. Limits are checked before a generation runs, not just reported after the fact — once a configured cap is reached, further generation is refused until it resets or an admin raises it. Only organization admins and owners can change these limits; other roles can view usage but not edit policy.

Security & Compliance

On-demand scans of your live infrastructure and your GitHub repositories for vulnerabilities and misconfigurations, rolled up into a posture score and severity breakdown (critical/high/medium/ low). Findings link back to the specific resource or file.

Templates & Compliance

Reusable stack templates and compliance framework tracking (e.g. CIS benchmarks) so common patterns and required controls don't have to be re-specified on every generation.

Memory

CloudEntail retains context across your sessions — prior decisions, naming conventions, environment layout — so it doesn't ask you to re-explain your setup every time. Memory entries can be pinned, shared with your team, or removed individually.

Integrations

GitHub

Connect a GitHub account under Settings → GitHub to push generated or promoted code as draft pull requests. CloudEntail always creates a feature branch — it never commits directly to main, master, or any protected branch. Auto-push (opening a PR on every generation automatically, rather than on request) is off by default and worth leaving off unless your team specifically wants that volume of PRs.

Jira

Connect Jira under Settings → Jira to generate infrastructure code directly from ticket descriptions: CloudEntail reads the ticket, finds a linked GitHub repo, generates code, and opens a draft PR. Both classic and Atlassian scoped API tokens are supported — scoped tokens are routed through the Atlassian API gateway automatically, with no manual configuration required.

Alerts

Configure notification channels — Slack, Email, PagerDuty, Microsoft Teams — for drift detection, apply results, and pipeline events (PR created, PR merged, pipeline stage complete or failed). You can configure more than one destination per channel type — for example a team Slack channel and a separate on-call channel — each independently named and independently triggered.

Team & Access

Organizations have four roles: owner, admin, developer, and viewer. Ownership can be transferred to any existing member. Anyone joining an organization after the first user goes through an approval step — a shared email domain is treated as a starting point for trust, not proof of membership on its own.

Security Model

• Server-side plan gating — destructive changes require an approved destroy request; a client-supplied flag cannot authorize destruction on its own.
• Injection-resistant generation — code-execution primitives and unapproved provider sources are blocked in generated and imported code, independent of what a prompt asks for.
• Tenant isolation — every tenant's infrastructure, credentials, and state are scoped at the database level, not just filtered in application code.
• Encryption at rest — cloud credentials and integration tokens (GitHub, Jira) are encrypted per-tenant via KMS before storage; nothing sensitive is stored in plaintext.
• Full audit trail — destroy requests, approvals, and rejections are recorded with who acted and why.

Troubleshooting & FAQ

Apply requires a recent, matching Plan to have run first. If the code changed after planning, re-run Plan.

It's waiting on admin approval. Check with an owner/admin in your organization; requests include the reason you provided so they have context to decide.

A reason (minimum 10 characters) is required on every destroy request — it's what the approver uses to decide, and it's part of the permanent audit record.

Drift reports are backed by a full plan; the summary line and the expandable raw output should both be present once a scan has completed for that stack. If a stack shows drifted with no detail, re-run the scan.

That's intentional — personal email providers can't be trusted to identify which company you belong to, so each such account gets an isolated organization rather than being grouped with strangers who share the same provider. Use a work email to join or create a shared organization.

This document reflects CloudEntail's current feature set. Have a question this page doesn't answer? support@cloudentail.com