> ## Documentation Index > Fetch the complete documentation index at: https://docs.nuon.co/llms.txt > Use this file to discover all available pages before exploring further. # Stacks > Customers use Stacks to install an app in their account. A Stack is the first thing deployed in a customer's cloud account when an install is created. It provisions the foundational resources needed to deploy and operate the app. For each install, Nuon generates a Stack template in both Terraform and the platform's native IaC language. Both formats produce the same resources, so you or your customer can use whichever one fits into your tooling and processes the best. * On **AWS**, the native format is a CloudFormation stack. * On **Azure**, the native format is an Azure Resource Manager (Bicep) deployment. * On **GCP**, only Terraform is generated — Google Cloud's Infrastructure Manager runs Terraform natively. ## What does a Stack create? Every Stack provisions the same three things: * The network the app runs in * The [permissions the Runner needs](/concepts/operation-roles#what-are-operation-roles) to deploy and operate your app * The Nuon-powered [Runner](/concepts/runners) itself The network can either be **created** by the Stack or **selected** from resources the customer already has. See [Stand-Alone VPC](/concepts/stacks/stand-alone-vpc), [Customer VPC](/concepts/stacks/customer-vpc), and [Customer Cluster](/concepts/stacks/customer-cluster) for each pattern. ## How is a Stack deployed? When a vendor creates an install, Nuon generates Stack templates (Terraform and the platform's native IaC, where applicable) along with links and CLI snippets the vendor can share with the customer. The customer deploys whichever format fits their tooling, using their own credentials. This is how access is granted: the customer provisions the Stack themselves. No cross-account access is required. The customer retains full ownership and visibility of all infrastructure created by the Stack. Install stack ## Customer Control The Stack gives the customer full control over the Runner's access to their cloud account. Through the Stack parameters, the customer can: * **Enable or disable the Runner** to stop it from executing jobs * **Configure IAM roles and policies** to control what the Runner can do * **Grant break glass roles** for temporary elevated access during emergencies, which the customer can revoke at any time * **Trigger automated actions** when roles are enabled or disabled — use the `role-enabled` and `role-disabled` [action triggers](/concepts/actions#role-change-triggers) to run auditing, validation, or setup tasks in response to role changes This means the customer always has a killswitch. See [Customer-Controlled Runner Shutdown](/guides/runner-kill-switch). ## Stack Inputs Stacks accept customer-provided values at deploy time. They come in three forms: * **[Secrets](/concepts/app-secrets)** — entered by the customer as CloudFormation/Bicep parameters or Terraform variables, then stored in the customer's cloud secret manager (e.g., AWS Secrets Manager). * **[Customer-facing inputs](/concepts/app-inputs#customer-facing-inputs)** marked `user_configurable` — passed through the Stack at deploy time. * **VPC and cluster IDs** — required when the app uses the [Customer VPC](/concepts/stacks/customer-vpc) or [Customer Cluster](/concepts/stacks/customer-cluster) pattern. The customer enters them in the Stack's parameter form alongside any other inputs.