---
name: azure-functions-deploy
description: "Proxy Azure Functions deployment requests to the Azure Skills prepare, validate, and deploy workflow while preserving Azure Functions-specific guidance"
---

> **Language**: Always respond in the same language the user is using.

# azure-functions-deploy — Deploy Azure Functions

Deploy your Azure Functions app to Azure by proxying to the Azure Skills deployment workflow.

This skill is the Azure Functions-facing entry point. It should not run deployment commands directly. It prepares Azure Functions-specific context, then delegates execution to `azure-prepare`, `azure-validate`, and `azure-deploy` from the Azure Skills plugin.

## Prerequisites

- Azure CLI installed and logged in (`az login`)
- Azure Developer CLI installed and logged in (`azd auth login`) for AZD-based deployments
- An Azure subscription (`az account show`)
- A Functions project with `host.json` in the current directory
- Azure Skills plugin installed with `azure-prepare`, `azure-validate`, and `azure-deploy` available

If any prerequisite is missing, suggest running **azure-functions-setup** first.

## Required delegation model

Before handing execution to Azure Skills or an approved fallback, read the
[verified deployment result contract](references/deployment-result.md).
Collect and freeze the approved subscription, tenant and cloud during planning.
Do not invoke deployment before that target is verified. Pass the frozen target
and resource-link requirements to the deployment engine; retain them for its result.

Use Azure Skills as the deployment engine:

1. If `.azure/deployment-plan.md` is missing, invoke `azure-prepare` first — **unless the shortcut path below applies**.
2. If `.azure/deployment-plan.md` exists but is not `Validated`, invoke `azure-validate` before any deployment attempt.
3. If `.azure/deployment-plan.md` exists and status is `Validated`, invoke `azure-deploy` directly.
4. Never mark the plan as `Validated` from this skill. Only `azure-validate` may do that.
5. Do not run `azd up`, `azd deploy`, `terraform apply`, `az deployment`, or `func azure functionapp publish` directly from this skill unless Azure Skills cannot handle the scenario and the user explicitly approves a fallback.

### Shortcut path for MCP-template projects

When a project was scaffolded from an Azure MCP template (e.g., via `azure-functions-create` Path A), it already contains complete infrastructure. Detect this by checking **all** of these conditions:

1. `azure.yaml` exists in the project root
2. `infra/main.bicep` or `infra/*.tf` exists
3. `host.json` exists
4. `azure.yaml` contains a `metadata.template` field (indicates MCP template origin)

If all conditions are met, **skip `azure-prepare`** and proceed directly:

1. Generate a lightweight `.azure/plan.md` noting the pre-existing infrastructure
2. Invoke `azure-validate` (provisions preview, environment setup)
3. Invoke `azure-deploy` (runs `azd up`)

This avoids the redundant 5–10 minute analysis and planning phase for projects that already have production-ready infrastructure.

The normal workflow is:

```text
azure-functions-deploy → azure-prepare → azure-validate → azure-deploy
```

When a validated plan already exists:

```text
azure-functions-deploy → azure-deploy
```

## Azure Functions context to inject

Before handing off, collect and pass the following Azure Functions-specific guidance to Azure Skills:

- Use Azure Functions deployment best-practices MCP guidance (`get_azure_bestpractices` with `resource: azurefunctions` and `action: deployment`) when available.
- Prefer Flex Consumption / FC1 for new serverless Function Apps.
- Include `functionAppConfig` with deployment storage for FC1 Function Apps.
- Use Linux for Python Function Apps.
- Configure Function authentication or stronger mechanisms; avoid anonymous access unless intentional.
- Enable Application Insights for monitoring, exception tracking, and dependency monitoring.
- Consider private networking and one Function App per independently scaling workload when appropriate.
- Use Azure Functions endpoint verification after deploy; do not use `curl -I` for HTTP trigger verification because HEAD can return false negatives.

## Go-specific deployment context

Go is in public preview, and Core Tools 4.12 or later owns the Go build and packaging. Lead with the supported commands rather than a hand-rolled package.

Two preview constraints are hard limits, so check them before planning anything else.

- Go function apps are supported **only on the Flex Consumption plan**.
- Go function apps run on **Linux only** in Azure. Do not select or attempt a Windows-hosted plan.

Supported deployment paths:

| Command | What it does |
| --- | --- |
| `func azure functionapp publish <APP_NAME>` | Builds, packages, and deploys to an existing function app. Simplest path. |
| `func pack` | Builds for Linux x64 and produces a deployable zip with the binary at the package root as `app`. Deploy it with `az functionapp deployment source config-zip`. |

A package produced by `func pack` is ready to run, so do not request a remote build when deploying it.

Other Go context to pass to Azure Skills:

| Concern | Guidance |
| --- | --- |
| Cross-compilation | Only needed with `func pack --no-build`. In that case build first with `CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/app .`. Otherwise Core Tools targets the right platform for you. |
| Executable permission | Core Tools sets this correctly. It only becomes a problem with a hand-rolled archive, because some tools such as Windows `Compress-Archive` do not preserve Unix permissions, which leaves the platform unable to start the binary. Prefer `func pack`. |
| Worker runtime setting | `FUNCTIONS_WORKER_RUNTIME` must be `native`. |
| Azure CLI version | 2.87.0 or later is required to create Azure resources or deploy packages for Go. |
| Preview status | Confirm the user accepts preview status before a production deployment. |

If a Go deployment succeeds but the app never becomes healthy, check the plan and OS first, then whether the package was built by Core Tools or assembled by hand.

Reference: https://learn.microsoft.com/azure/azure-functions/functions-reference-go

## Azure Skills plugin installation guidance

If Azure Skills is unavailable, stop and ask the user to install it for their host:

| Host | Install guidance |
| --- | --- |
| GitHub Copilot CLI | `/plugin marketplace add microsoft/azure-skills`, then `/plugin install azure@azure-skills` |
| Claude Code | `/plugin install azure@claude-plugins-official` |
| Codex CLI | `codex plugin marketplace add microsoft/azure-skills`, then install `azure` from `/plugins` |
| VS Code | Install the Azure MCP extension and companion Azure Skills integration, then reload VS Code |
| GitHub Copilot fallback | `npx skills add https://github.com/microsoft/azure-skills/tree/main/.github/plugins/azure-skills/skills -a github-copilot -g -y` |

## Fallback policy

Prefer Azure Skills for all deployment execution. Use a Functions-specific fallback only when:

- Azure Skills cannot be installed or invoked in the current host,
- the user explicitly asks for a quick publish to an existing Function App, or
- a scenario is not covered by Azure Skills and must be handled by Azure Functions Core Tools.

Before using a fallback, explain what will be skipped compared with `azure-prepare` → `azure-validate` → `azure-deploy`, and ask for confirmation.

## Post-deploy verification

Use the frozen destination and verified deployment result contract to return a
**Function App in Azure Portal** link separately from the app endpoint URL.
An endpoint URL or optional provisioning deployment link is not a substitute.
If identity lookup is unavailable, preserve the actual deployment outcome and
explain why its resource link is unverified; do not retry deployment to fix a link.
Canvas result reporting applies only when the request supplied an active run.

Let `azure-deploy` own post-deploy verification. Add Azure Functions-specific reminders when relevant:

- List deployed functions and verify the app is running.
- Test HTTP trigger endpoints with GET, not HEAD.
- Suggest `azure-functions-health-status` for runtime health, metrics, and Application Insights checks.
- Suggest `azure-functions-best-practices` for production readiness after successful deployment.

## Monitoring `azd up` progress

The `azd up` command uses animated progress bars that may not render correctly in agent terminal capture. If the output appears stuck on a spinner (e.g., repeated "Initialize bicep provider"), the deployment is likely still progressing normally in the background.

To monitor deployment progress independently:

```bash
# Check resource group creation
az group show --name rg-<env-name> -o json

# Check deployment status
az deployment group list --resource-group rg-<env-name> \
  --query "[].{name:name, state:properties.provisioningState}" -o table

# Check Function App status
az functionapp list --resource-group rg-<env-name> \
  --query "[].{name:name, state:state}" -o table
```

Do not kill and restart the `azd up` process based solely on lack of terminal output. Instead, use the commands above to verify whether the deployment is progressing.

## After Deployment

> ✅ Your app is deployed through Azure Skills. Consider running `azure-functions-best-practices` for a production readiness review.

## Next steps

- On missing Azure Skills, suggest `azure-functions-setup` to install or configure the Azure Skills plugin.
- On missing or unvalidated plan, invoke `azure-prepare` and `azure-validate` before `azure-deploy`.
- On successful deployment, suggest `azure-functions-best-practices` for production readiness.
- On deployment failure, suggest `azure-functions-diagnostics` after `azure-deploy` error recovery is exhausted.