arn-infra-deploy

Arness Infra Deploy

Execute infrastructure deployment to a target environment with environment promotion enforcement, CI/CD pipeline awareness, cost gates, safety layers, and post-deployment resource tracking. This skill orchestrates the actual apply/deploy step, producing handoff files with secret references and updating the issue lifecycle.

This skill is expertise-adaptive: beginner users deploy via platform CLI commands (fly deploy, railway up), while intermediate and expert users deploy via IaC tools (tofu apply, pulumi up). All experience levels receive the same safety protections.

Prerequisites

Read ## Arness from the project's CLAUDE.md. If no ## Arness section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run /arn-infra-wizard to get started — it will set everything up automatically." Do not proceed without it.

Extract:

• Deferred -- if yes, inform the user that infrastructure is deferred and suggest running /arn-infra-assess first. Stop.
• Experience level -- derived from user profile. Read ~/.arness/user-profile.yaml (or .claude/arness-profile.local.md if it exists — project override takes precedence). Apply the experience derivation mapping from ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md. If no profile exists, check for legacy Experience level in ## Arness as fallback.
• Providers -- which cloud providers are configured
• Providers config -- path to providers.md for per-provider details and IaC tool overrides
• Default IaC tool -- the default IaC tool to use when no per-provider override exists
• Environments -- environment names in promotion order
• Environments config -- path to environments.md for promotion pipeline and deployment state
• Tooling manifest -- path to tooling-manifest.json for tool availability checks
• Resource manifest -- path to active-resources.json for resource tracking
• Cost threshold -- monthly budget limit for cost gate warnings
• Validation ceiling -- maximum validation level before requiring explicit approval
• Platform -- for issue label management
• Issue tracker -- for issue lifecycle transitions
• Infra specs directory -- from ## Arness config, for locating INFRA spec and handoff files (default: .arness/infra-specs)

Read the provider configuration:

Read <providers-config-path>

Read the environment configuration:

Read <environments-config-path>

Workflow

Step 1: Determine Target Environment and Promotion Validation

Ask the user which environment they want to deploy to (if not already specified in the invocation):

"Which environment would you like to deploy to? [list environments from config in promotion order]"

Environment promotion enforcement:

Read the promotion pipeline from environments.md. Enforce the following rules:

1. No skipping stages: If the promotion pipeline is dev --> staging --> production, the user cannot deploy directly to production unless staging has been deployed and verified. Check the Last deployed field for each environment in the pipeline.

1. Refuse direct-to-prod when staging exists: If the promotion pipeline includes a staging environment and the user requests deployment to production:
2. Check if staging has been deployed (has a Last deployed timestamp)
3. Check if staging has been verified (has arn-infra-verified label or lastVerified in resource manifest)
4. If staging has NOT been deployed or verified: refuse with "Production deployment requires staging to be deployed and verified first. Run /arn-infra-deploy targeting staging, then /arn-infra-verify to validate it."
5. If staging IS verified: proceed with production deployment

1. First deployment to any environment is allowed: If no environment in the pipeline has been deployed yet, allow deployment to the first environment in the pipeline (typically dev or staging).

Step 2: CI/CD Enforcement

Check whether CI/CD pipelines exist for the target environment.

Scan for pipeline configurations:

• .github/workflows/ -- GitHub Actions
• .gitlab-ci.yml -- GitLab CI
• bitbucket-pipelines.yml -- Bitbucket Pipelines

If pipelines exist AND the target is staging or production:

Warn: "I detected CI/CD pipelines in this project. For staging and production deployments, CI/CD is the recommended deployment method -- it ensures reproducibility, audit trails, and team visibility."

Ask (using AskUserQuestion):

"How would you like to deploy?"

Options:

1. Use CI/CD -- Trigger the pipeline (I will help you push and monitor)
2. Deploy locally -- Proceed with local deployment (not recommended for staging/prod)
3. Cancel -- Do not deploy

If the user chooses CI/CD: help them trigger the pipeline (e.g., git push, gh workflow run) and monitor the deployment. Skip to Step 8 for post-deployment tracking.

If the user chooses local deployment: proceed with a warning logged and continue to Step 3.

If no pipelines exist OR the target is dev: Continue to Step 3 without CI/CD enforcement.

Step 3: Pre-Deployment Safety Checklist

Read the local override or plugin default for deployment-safety-checklist.md.

Run the pre-deployment safety checklist. For each gate:

1. IaC validation: Has the IaC been validated? Check if arn-infra-define has been run and the validation ladder passed. If not, suggest running /arn-infra-define first.

1. Security scan: Has a security scan been performed? (Level 2 validation). If the validation ceiling is >= 2 and no scan has been run, warn.

1. Cost estimation: Has a cost estimate been produced? Compare against the cost threshold. If the estimate exceeds the threshold, present a cost gate warning requiring explicit acknowledgment.

1. State lock check: For IaC tools that support state locking (OpenTofu, Terraform, Pulumi), verify that the state is not locked by another deployment. If locked, warn and ask whether to wait or force-unlock.

1. Rollback plan: Ensure a rollback strategy exists. Load the rollback patterns reference:

> Read the local override or plugin default for rollback-patterns.md.

1. Pending changes diff: Show the user what will change compared to the current deployed state. For IaC tools, use plan/preview output and save the plan file for exact apply:
2. OpenTofu: tofu plan -var-file=environments/<env>.tfvars -out=deploy.tfplan
3. Terraform: terraform plan -var-file=environments/<env>.tfvars -out=deploy.tfplan
4. For PaaS, show config diffs.

CDK users: The deployment will use --require-approval never because CDK does not support saved plan files. The safety checklist above replaces CDK's built-in approval prompt.

Present the checklist results:

"Pre-deployment checklist for [environment]:

• [ ] IaC validated: [status]
• [ ] Security scan: [status]
• [ ] Cost estimate: [$X/month] vs threshold [$Y/month] -- [PASS/EXCEEDED]
• [ ] State lock: [free/locked]
• [ ] Rollback plan: [available/not available]
• [ ] Changes: [summary of resources to create/modify/destroy]

Proceed with deployment?"

User confirmation is required for ALL deployments. Never auto-deploy.

Step 4: Execute Deployment

Based on the experience level and provider configuration, execute the deployment.

Beginner path (platform CLI):

Map the provider to the appropriate deploy command:

• Fly.io: fly deploy --app <app-name> [--env <environment>]
• Railway: railway up [--environment <environment>]
• Render: deploy via dashboard or render deploy (if CLI available)
• Vercel: vercel --prod (production) or vercel (preview)
• Netlify: netlify deploy --prod (production) or netlify deploy (draft)

Run the command and stream output to the user.

Intermediate / Expert path (IaC tool):

Map the IaC tool to the appropr