> For the complete documentation index, see [llms.txt](https://docs.duplocloud.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.duplocloud.com/docs/extension-framework/case-studies/devops-platform.md). # AI-Native DevOps Platform DuploCloud's AI DevOps platform is the first production application built on the Extension Framework. It demonstrates how a complex, multi-resource, dependency-rich operational domain can be automated with AI while giving business users a traditional enterprise Ops application experience. Cloud infrastructure provisioning — historically the domain of senior engineers with deep AWS or Kubernetes expertise — becomes a structured, ticket-driven workflow that any authorized team member can initiate and monitor in real time. ## The Policy Model The DevOps extension defines resources that mirror how cloud infrastructure is actually organized. Each layer depends on the one below it, and the framework enforces those dependencies at the UI level. * **Network** — the foundation. VPC, subnets, routing, internet gateways, NAT gateways. Everything else depends on a network. * **Cluster** — a Kubernetes cluster (EKS, AKS, GKE) provisioned inside a network. Inherits VPC and subnet configuration from its parent network automatically. * **Environment** — a logical grouping within a cluster. Contains security groups, IAM roles, KMS keys, and serves as the boundary for workload deployment. * Within an Environment, the full resource tree expands: **Namespaces**, **Nodes**, **Workloads** (Deployments, StatefulSets, Jobs), **Configs** (ConfigMaps, Secrets), **Storage**, **Networks**, and **Cloud Resources** (Hosts, Serverless, Databases). The dependency chain runs in one direction: Network → Cluster → Environment → Workloads. A resource at any level cannot be created without its parent already being provisioned. ## Creating a Network The network creation workflow illustrates the full Extension Framework lifecycle from form submission through live agent execution to a browsable result. 1. The user clicks **Create Network Baseline** and fills out a two-step form. Step 1 collects the name, account (scope), and an optional skill override. Step 2 collects the spec: region, VPC CIDR, availability zones, NAT gateway toggle, and subnet prefix. The platform auto-computes subnet ranges from the CIDR and displays them in a preview table before the user submits. 2. After clicking **Create & Provision**, a provisioning ticket is created immediately. The user lands on the ticket view and watches the agent work in real time — reading the skill, reading the spec, planning the CloudFormation stack (11 resources: VPC, DNS, Internet Gateway, public and private subnets, route tables, and associations), and deploying to AWS. The ticket sidebar shows the scope, attached skills, running cost, and ticket ID throughout. 3. Once provisioning completes, the network detail view shows the VPC ID (linked), with tabs for **Overview** (VPC ID, CIDR, Region, VPC State, Internet Gateway, IGW State, Flow Logs), **Subnets**, and **Routing**. The **Spec** and **Result** tabs are available for inspection. Status shows **Ready**. A **Track Provisioning Status** button links directly to the underlying ticket for troubleshooting or audit. ## Creating a Cluster Cluster creation demonstrates dependency enforcement in practice. The cluster form's **Network Source** field offers two options: * **Choose Network** — select from networks already provisioned in the platform. Region, VPC ID, and subnet configuration are inherited automatically; the user does not re-enter them. * **Choose VPC** — manual entry for cases where the VPC was created outside the platform. The framework blocks cluster creation if no network exists. The UI reflects this by showing only valid, ready-state networks in the selection list. There is no way to submit the form with a missing or unprovisioned network dependency. ## Navigating an Environment The environment detail view exposes the full resource tree through the left navigation panel: * **Overview** — security groups, IAM roles, KMS keys, and the Spec/Result tabs for the environment itself. * **Micro Services** — deployed application services scoped to this environment. * **Kubernetes** — Namespaces, Nodes, Workloads, Configs, Storage, Networks. * **Cloud Resources** — Hosts, Serverless, Storage, Databases, Networks, Configs. Each sub-resource category has its own list view, create form, and detail view. The entire tree is generated by the framework from the policy model definition — no custom UI code is required for any of it. ## Skills in Action The DevOps extension ships with platform skills such as `duplo-aws-infra`, which contains CloudFormation templates, IAM policies, security group rules, and provisioning scripts. Users can view the skill files directly from the ticket sidebar at any point during or after execution. Because skills are user-modifiable, an organization can fork a platform skill and customize it — adding their own tagging policies, compliance requirements, or architectural standards — without waiting for DuploCloud to release an update. The skill is the business logic. The framework executes it; the organization owns it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.duplocloud.com/docs/extension-framework/case-studies/devops-platform.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.