Generated banner for Python Appservice Deploy
Generated logo for Python Appservice Deploy

Python Appservice Deploy

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Workflow
  • Cloud and DevOps
  • MIT
  • Low risk
  • Has scripts

From the author

Deploy Python (Flask/Django/FastAPI) code to Azure App Service Linux. WHEN: "Flask App Service", "Django App Service", "FastAPI App Service", "deploy Python to App Service". DO NOT USE FOR: Container Apps, Functions, non-Python, Terraform/Bicep/IaC, full infra — use azure-prepare.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured, idempotent workflow for deploying Python applications (Flask, Django, FastAPI) to Azure App Service on Linux. It handles the creation of necessary Azure resources—including Resource Groups, App Service Plans (P0v3), and Web Apps—while enforcing best practices like server-side builds and proper startup configuration. The process includes automated normalization of shell scripts to ensure compatibility and provides a reliable path for both standard CLI-based deployments and those utilizing Azure Developer CLI (azd) configurations.

What it does

  • Automatically creates or validates Azure Resource Groups, App Service Plans, and Web Apps.
  • Configures server-side builds via SCM_DO_BUILD_DURING_DEPLOYMENT.
  • Normalizes Linux shell scripts to prevent line-ending issues during deployment.
  • Sets appropriate startup commands for FastAPI applications.
  • Packages the application code into a clean ZIP archive, excluding unnecessary files.
  • Supports both standard Azure CLI and azd-based deployment workflows.

When to use it

  • When you need to deploy a Python Flask, Django, or FastAPI application to Azure App Service Linux.
  • When you want to automate the provisioning of the required Azure infrastructure alongside the code deployment.
  • When you need a repeatable, error-checked deployment process for Python web apps.
  • When you are working with a standard Python project structure and require a reliable deployment pipeline.

Advantages

  • Reduces manual configuration by deriving sensible defaults for resource names and regions.
  • Ensures cross-platform compatibility by normalizing line endings in scripts.
  • Prevents common deployment failures through pre-packaging validation.
  • Provides a consistent, idempotent approach to resource creation.
  • Integrates seamlessly with existing Azure CLI and azd workflows.

Usage examples

“Deploy my Flask app to Azure App Service.”
The agent will prompt for an app name, then automatically create the necessary Resource Group, P0v3 Linux App Service Plan, and Web App, finally deploying the code.
“Deploy my FastAPI project to Azure.”
The agent will configure the Web App with the required uvicorn startup command and deploy the code to an Azure App Service Linux instance.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/python-appservice-deploy/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip python-appservice-deploy.zip -d .agents/skills

Documentation by Microsoft

Python on Azure App Service — Code Deploy

Deploys Python (Flask, Django, FastAPI, generic) code to Azure App Service Linux (P0v3, Python 3.14). Creates RG + Plan + Web App if missing. Hand off to azure-prepare for VNet, Key Vault, databases, or IaC.

MCP tools used: mcp_azure_mcp_subscription_list, mcp_azure_mcp_group_list, mcp_azure_mcp_appservice, mcp_azure_mcp_azd (when azure.yaml is present).

Workflow

Prerequisite: Verify the latest stable Azure CLI; update with approval and recheck if needed.

  1. Resolve context — smart defaults, minimal prompts. Only the app name is interactive; RG (<app>-rg), Plan (<app>-plan), region (current az default or eastus2), subscription are derived. create-app.md §1.

  2. Detect framework (advisory, never blocks). detect.md.

  3. Choose path — azure.yaml host: appservice → deploy-azd.md; else deploy-azcli.md.

  4. Ensure RG → Plan (P0v3 --is-linux) → Web App (--runtime "PYTHON:3.14") exist. Before creating a plan, invoke azure-quotas to check quota availability. On transient ARM errors, follow transient-retry.md. create-app.md.

  5. Set startup — Flask/Django: none (Oryx auto-detects). FastAPI: always python -m uvicorn main:app --host 0.0.0.0. Other: warn. startup-commands.md.

  6. Set SCM_DO_BUILD_DURING_DEPLOYMENT=true.

  7. Deploy — azd deploy or az webapp deploy --type zip --track-status false --enriched-errors true.

  8. STOP. Print the post-deploy message (post-deploy-message.md) and end the turn.

Hard rules
  • LINUX SCRIPTS — normalize selected shell/startup files to LF, then verify no CR bytes remain. Stop on normalization, validation or packaging failure; deploy only a fresh package.

  • DJANGO REMOTE BUILDS — require STATIC_ROOT and successful system/collectstatic checks before packaging.

  • ⛔ NO POST-DEPLOY VERIFICATION — after deploy returns, do not run az webapp log tail, curl, Invoke-WebRequest, or any health probe. App Service needs 2–3 min to warm; a quiet log or early 5xx is not failure.

  • ⛔ SHELL SAFETY — for --runtime always use "PYTHON:3.14" (colon). Never "PYTHON|3.14" (pipe is a shell operator).

  • ⛔ NEVER az webapp up — deprecated. Use Step 7 commands.

  • ✅ URL FORMAT — present endpoints as https://... URLs.

Error Handling

See errors.md for the full symptom → cause → fix matrix. Quick triage: missing plan/app → re-run Step 4; container ping timeout on 8000 → fix startup (Step 5); ModuleNotFoundError after deploy → ensure Step 6 ran, redeploy.

Files

references/post-deploy-message.md

Post-deploy message to the user

After az webapp deploy / azd deploy returns successfully, the skill is done. Do not run any further verification commands.

Hard rules

  • ⛔ Never run az webapp log tail as a "confirm startup" step — logs are often quiet for 1–2 min during build/warm-up; silence is not a failure signal.

  • ⛔ Never run curl, Invoke-WebRequest, wget, or any HTTP request against the deployed URL — first request often 502s or times out on a healthy deploy.

  • ⛔ Never present an early 5xx or quiet log stream as a deploy failure — the deploy succeeded; the platform just isn't warm yet.

  • ✅ Always give the user the URL, the wait expectation, and the log command, then stop.

Message template — standard (Flask / Django / FastAPI)

Use this when Step 2 detected a known framework (flask, django, or fastapi). Print exactly this (substituting the real values) as the final output of the skill, then end the turn:

✅ Deployment complete.

🌐 App URL: https://<app>.azurewebsites.net
   It can take 2–3 minutes for the site to be reachable while App Service finishes
   warming up the container. Open it in your browser after a short wait.

📜 If you want to watch live logs:
   az webapp log config -n <app> -g <rg> --application-logging filesystem --level information
   az webapp log tail -n <app> -g <rg>
   (The first command is a one-time prereq on a fresh app — without it the stream stays empty.)

Message template — unknown framework

Use this when Step 2 detected wsgi-generic, asgi-generic, or unknown (i.e. not Flask, Django, or FastAPI). The code is already deployed and SCM_DO_BUILD_DURING_DEPLOYMENT=true is set, but Oryx will not know how to start the app until the user sets a startup command. Print this instead:

✅ Code deployed — but framework not detected.

🌐 App URL: https://<app>.azurewebsites.net
   It can take 2–3 minutes for App Service to finish building and start the
   container. The site will likely return an error page until you set a
   startup command (next step).

⚠️  We could not detect Flask, Django, or FastAPI in your project, so no
   startup command was set automatically. Set one with:

   az webapp config set -n <app> -g <rg> \
     --startup-file "<your-startup-command>"

   Examples:
     • Generic WSGI (gunicorn):
         gunicorn --bind=0.0.0.0 --timeout 600 <module>:<callable>
     • Generic ASGI (uvicorn):
         python -m uvicorn <module>:<callable> --host 0.0.0.0 --port 8000

   See references/startup-commands.md for more guidance.

📜 If you want to watch live logs:
   az webapp log config -n <app> -g <rg> --application-logging filesystem --level information
   az webapp log tail -n <app> -g <rg>
   (The first command is a one-time prereq on a fresh app — without it the stream stays empty.)

Replace <module>:<callable> with the user's actual entry point (e.g. app:app, main:application, myapp.wsgi:application). If you can identify a likely entry point from the source code, suggest a concrete command instead of leaving placeholders.

Logging tips (mention only if the user asks for them)

⚠️ Prereq for az webapp log tail on a fresh app: filesystem logging must be enabled or the live stream stays empty. Run once:

az webapp log config -n <app> -g <rg> \
  --application-logging filesystem --web-server-logging filesystem --level information
az webapp log config -n <app> -g <rg> `
  --application-logging filesystem --web-server-logging filesystem --level information

Deployment-build logs do not require this — read them with az webapp log deployment list/show.

LogCommand
Deployment historyaz webapp log deployment list -n <app> -g <rg>
Deployment detailsaz webapp log deployment show -n <app> -g <rg> --deployment-id <id>
Full log downloadaz webapp log download -n <app> -g <rg>

Picking which template to use

Detected framework (Step 2)Template
flask, django, fastapistandard
wsgi-generic, asgi-generic, unknownunknown framework

What "success" means here

Either of these is enough to print the success message — do not gate on log output or an HTTP probe:

  • az webapp deploy returned without an error, or

  • azd deploy printed SUCCESS: Your application was deployed to Azure

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills · .github/plugins/azure-skills/skills/python-appservice-deploy · commit 0696600
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download python-appservice-deploy.zip