Leveraging CURSOR and Azure Services for Rapid Web Deployment

Review and execution boundary

Historical Flask/Python 3.12 app; current documentation explains build automation, not a replay of the 2024 deployment.

Reviewed on 7 October 2026 against the official source snapshots linked below. The review is bounded editorial correction, not certification of every dependency, security property or cloud deployment. Historical setup commands and optional exercises were not executed. No cloud resources, third-party packages or external side effects were created. Old screenshots and unavailable private assets remain in the private recovery archive, not prerequisites for this lesson.

Rapid development and deployment using AI tools

Generating a Flask website with Cursor gave me a starting point, but making it repeatably deployable required a separate set of decisions: reproduce the Python environment, connect the repository to Azure, and tell the host how to start the app. This walkthrough follows that deployment path for the original blogging app, then returns to the authentication and configuration work that AI-generated code did not solve for me.

Key Components

1. Cursor: An AI-assisted development environment to generate frontend and backend code.
2. Azure: Microsoft's cloud platform for deployment and hosting web app.
3. GitHub Actions: For continuous integration and deployment

Setup and Development

Locally to run the app using conda environment

To run the app locally, we need to setup conda environment and install all required packages.

1. Create a new conda environment

   conda create -n blogger python=3.12

2. Activate the conda environment

   conda activate blogger

3. Install the required packages

   pip install -r requirements.txt

    blinker==1.6.2
    certifi==2024.8.30
    charset-normalizer==3.3.2
    click==8.1.7
    Flask==3.0.3
    idna==3.8
    itsdangerous==2.2.0
    Jinja2==3.1.4
    Markdown==3.7
    MarkupSafe==2.1.3
    pip==24.2
    python-dotenv==1.0.1
    requests==2.32.3
    setuptools==72.1.0
    urllib3==2.2.2
    Werkzeug==3.0.3
    wheel==0.43.0

Git repo for the project

As we will be using GitHub Actions for CI/CD, we need to setup a git repo for the project.

Git repo : https://github.com/dinesh-coderepo/blogsite

Package Management

To capture all required packages for deployment, whenever any new package is required first we locally install them in conda env, while deploying we use requirements.txt to install all the dependencies in virtual env. So keep running the below command whenever any new package is installed in conda env to maintain same package versions in App service env.

To get all the packages, which then can be installed later using pip

This is needed while deploying using GitHub Actions and while setting up virtual env

pip list --format=freeze > requirements.txt

Create a webapp in Azure :

With the code and dependency list in Git, the next boundary is the runtime that will host them. The Web App configuration below uses Python 3.12 to match the local environment; creating the resource makes a deployment target, not yet a running copy of the application.

1. Go to Azure portal and create a new resource.
2. Search for "Web App" and select it.
3. Fill in the required fields and create the webapp, select python 3.12 as the runtime stack.

Setup GitHub Actions for CI/CD

1. Go to deployment center in the webapp and select GitHub actions.
2. Select your code repo and complete the setup.
3. Each time we push the code to GitHub, GitHub Actions will automatically run and deploy the code to Azure.

The repository connection sets up the delivery path. A successful workflow run and a working application are separate checks: Azure still needs the correct startup command, dependencies and runtime configuration to serve requests.

Azure Web App Configuration

In the Azure portal:

1. Go to "Configuration" under the "Settings" section.

2. In the "General settings" tab, find the "Startup Command" field.

3. Enter the following command:

   gunicorn --bind 0.0.0.0:8000 src.app:app

This tells Azure to run gunicorn and look for the app object in the src.app module.

Domain Configuration

• Azure Web App domain: blogging.azurewebsites.net
• Custom domain bound to the web app: dineshblog.com

Development Process

1. Learning Resources and Code Generation:

   • Microsoft Learn: Building AI web apps with Python and Flask
   • MDN Web Docs: HTML basics
   • Most of the code is generated using Cursor, with some modifications and additions by me.
   • Having high level understanding on what to develop is good, for blogging I am using markdown as my primary format to write blogs, to run this using flask.
   • Most of the html and CSS is generated keeping this in mind.
   • Also added a translation feature which you will find in the above tutorial.

2. Version Control:

   • Project repository: https://github.com/dinesh-coderepo/blogsite

3. Azure Service Principal:

   • The additional service principal is created to access the Azure Key Vault, this is done by creating an app registration and adding the service principal to have read access to the key vault.
   • Keep in mind we will be using two service principles, one for deployment using GitHub Actions and other for access azure services.
   • In order to have these keys for the Translation API, the historical setup generated a local .env file; the corrected runtime approach uses managed identity/Key Vault and does not package that file
     • Note: To access the Azure Key Vault, the service principal needs to be added to federated credentials in the app registration.

4. Deployment:

   • The deployment is done using GitHub Actions, the workflow is defined in the .yml file.
   • Successfully deployed using GitHub Actions: Deployment Log

Key Learnings and Tips

1. Service Principal Authentication: To login to a service principal and access the key vault, use a supported credential method and separately grant the required Key Vault data-plane permission; federation is one CI option, not a universal prerequisite.

2. Continuous Integration: The project uses GitHub Actions for CI/CD, ensuring smooth and automated deployments.

3. Resource Management: Proper configuration of Azure resources, including the web app , custom domain , Azure key vault and service principal. Resources created normally are not accessible to the GitHub Actions workflow, this is done by adding the service principal to the app registration and adding it to the federated credentials.

4. AI-Assisted Development: Cursor helped generate the initial Flask and HTML/CSS structure quickly. The deployment work still required understanding the runtime, workflow and authentication settings well enough to correct suggestions that did not fit this app.

Next Steps: Enhancing the Blog

For the next iteration, I plan to implement a blog-style website with a modern touch:

• Enhance the UI/UX to make it more modern and responsive.
• Add other tools like calculator to the blog site.
• Keep the blog updated with new content.

Conclusion

For this project, Cursor IDE (trial pro version) was useful for generating the Flask backend and HTML/CSS boilerplate and iterating locally. The harder boundary was integration: Azure App Service, the GitHub workflow, Key Vault and authentication all required corrections beyond the generated code. The reusable result is a working deployment path to improve in small iterations, not evidence that an LLM can independently deliver a production-oriented product. Treat the identity and secret-handling notes above as a record of this setup, not a complete security guide; deployment authentication and application access to Key Vault need separate permissions and validation.

Corrected contracts and failure analysis

The deployment principal and runtime identity have different jobs. Workload identity federation is one way for CI to authenticate; it is not a universal prerequisite for Key Vault access and does not grant permissions by itself. Prefer managed identity for supported runtime access and a scoped federated CI identity for deployment. Do not generate and publish an .env file containing production keys.

App Service build automation locates dependency metadata at the application root. A dependency list copied from a workstation can include irrelevant tools and omit system dependencies; record direct requirements, resolve a reviewed lock and test a clean environment. The startup module must match the packaged directory layout and Gunicorn must be an explicit dependency. Source deployment with Oryx and a prebuilt ZIP/container are different contracts: enabling a build is not implicit for every ZIP.

A successful CI job proves the job completed, not that the route, identity, custom domain and rollback work. Record artifact hash, runtime selection and independent health/auth checks.

Boundary exercise with solution

CI deploys successfully but startup says gunicorn not found. Which boundary failed?

Source-backed review notes

• Configure Linux Python Apps - Azure App Service | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “The App Service deployment engine automatically activates a virtual environment and installs dependencies from a requirements.txt, pyproject.toml, or setup.py file when you deploy a Git repository or when you deploy a zip package with build automation enabled.”
• Managed identities for Azure resources - Managed identities for Azure resources | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services. Manual handling of secrets and certificates are a known source of security issues and outages. Managed identities eliminate the need for developers to manage these credentials. Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials.”
• Use Key Vault References as App Settings - Azure App Service | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “If the secret version isn't specified in the reference, the app uses the latest version that exists in the key vault. When newer versions become available, such as with rotation, the app is automatically updated and begins using the latest version within 24 hours.”