Need help for deploying code to azure function app

Hello Likitha,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

To answer your questions, the issues you are encountering are a mix of expected architectural behavior on the Flex Consumption plan and local environment configuration on your self-hosted runner.

Here is the breakdown of the supported paths and recommendations based on official Microsoft documentation:

1. Recommended Deployment Method for Flex Consumption

The Flexible Consumption plan does not utilize the traditional Kudu/SCM site. Because the Kudu APIs are unavailable, using a Publish Profile will always result in a 401 Unauthorized error when attempting to reach /api/settings.

The officially supported deployment mechanism is using OIDC (Azure AD) authentication combined with the Azure CLI or the Azure Functions GitHub Action.

The Azure CLI error you are seeing ([SSL: UNEXPECTED_EOF_WHILE_READING]) is not a limitation of Azure, but a Python certificate validation failure on your GitHub self-hosted runner. Because the Azure CLI is written in Python, it relies on its own certificate store rather than the OS-level trust store. When your corporate proxy intercepts the SSL traffic, the CLI rejects the proxy's certificate.

• The Fix: You need to export the corporate proxy's Root CA certificate and set the REQUESTS_CA_BUNDLE environment variable on your self-hosted runner to point to that certificate file. This will allow the Azure CLI to trust the proxy and successfully upload the ZIP to the ARM API.

2. Upgrading to Standard or Premium

Standard and Premium plans do include the full App Service architecture, which restores full Kudu/SCM access and Publish Profile support. However, upgrading just to bypass a local proxy certificate issue is not strictly necessary. Once the REQUESTS_CA_BUNDLE variable is configured on your runner, deployments to Flex Consumption will succeed.

3. Plan Suitability for Your Workload

For a workload that triggers every 5 minutes, connects to Pulsar, and calls an API, Flexible Consumption is highly recommended. * Networking: Flex Consumption provides native VNET integration, allowing secure, private connections to Pulsar.

• Execution & Cold Starts: Because it runs every 5 minutes, the instances will largely stay warm. If you find that cold starts are impacting your API latency, Flex Consumption supports defining Always Ready instances, giving you pre-warmed workers without the higher baseline cost of a Premium plan.

References:

• Flex Consumption Deployment Mechanics
• Work behind a proxy with Azure CLI

If configuring the certificate bundle does not resolve the CLI error, could you provide the specific steps and a sanitized version of your GitHub Actions workflow YAML? Setting up a script to reproduce your exact runner configuration within a test Azure environment will help isolate the remaining deployment blocks.

1. Recommended deployment method for Flex Consumption

For Function Apps on the Flex Consumption plan, the supported deployment pattern is zip deployment to the function app using Azure tooling, not direct Kudu/SCM interaction:

• Flex Consumption apps use a Blob storage container to host .zip package files that contain the project code and all required libraries.
• Recommended deployment for Flex Consumption is:
  • Build the app
  • Create a .zip of the project root
  • Deploy using:
    • az functionapp deployment source config-zip (with optional --build-remote true for remote build in JavaScript scenarios)

From the documentation:

For deployment, Flex Consumption plan apps use a Blob storage container to host .zip package files that contain your project code and all libraries that are required for your app to run.

You can use the Azure CLI to upload a deployment package file to the deployment share for a function app in Azure.

az functionapp deployment source config-zip --src <FILE_PATH> --name <APP_NAME> --resource-group <RESOURCE_GROUP> --build-remote true

For CI/CD, the supported and recommended approach is to use GitHub Actions or Azure Pipelines to:

1. Build the Functions project.
2. Produce a deployable package (.zip).
3. Deploy that package to the Function App using the Azure Functions deployment action / Azure CLI.

The documentation explicitly calls out GitHub Actions and Azure Pipelines as the supported continuous deployment mechanisms for Functions, including Flex Consumption:

Azure Functions has both a custom GitHub Action and a custom Azure Pipelines Task to support continuous deployment.

So, the supported pattern is:

• Use GitHub Actions workflow that:
  • Authenticates to Azure (OIDC or publish profile stored as a GitHub secret).
  • Builds the app.
  • Deploys via the Azure Functions action / config-zip to the Flex Consumption Function App.

The issues described (401 on Kudu app settings, SSL inspection on Kudu) are environmental/plan-specific limitations around Kudu/SCM, not a lack of support for Flex Consumption deployment itself. Flex Consumption deployment is supported via zip deployment, not via relying on Kudu app-settings APIs.

2. Moving to Standard or Premium for full Kudu support

The provided context does not explicitly compare Kudu feature parity between Flex Consumption and Premium/Standard plans. It does, however, show that:

• Continuous deployment for Functions is supported across plans using GitHub Actions and Azure Pipelines.
• The Azure Functions GitHub Actions guidance assumes a working Function App with deployment credentials (publish profile or identity) and uses the Azure Functions action to deploy.

Because the context does not explicitly state Kudu/SCM behavior differences between Flex Consumption and Premium/Standard, only the following can be stated from the documentation:

• Flex Consumption deployment is supported and expected to work via zip deployment and GitHub Actions.
• The official guidance for GitHub Actions is plan-agnostic and applies to “a working function app hosted on Azure with source code in a GitHub repository.”

No additional, explicit guarantee from the context can be provided that moving to Standard or Premium will “restore full Kudu support” or resolve proxy-related SSL inspection issues. Those proxy/SSL issues are environmental and would still affect any plan if the same Kudu endpoints are inspected by the corporate proxy.

3. Plan suitability for a 5‑minute polling workload

From the context, the only plan-specific details available are about Flex Consumption deployment and the note that Linux Consumption plan is planned for retirement (not Flex Consumption). The context does not provide detailed cost, scaling, or reliability comparisons between Flex Consumption, Premium, and Standard for a specific workload pattern.

What can be stated from the documentation:

• Flex Consumption supports standard CI/CD via GitHub Actions and Azure Pipelines.
• Flex Consumption uses zip deployment to Blob storage and supports remote build where applicable.

The context does not include enough information to definitively recommend Flex Consumption vs Premium vs Standard for a specific “every 5 minutes, Pulsar + API calls” workload.

From the available documentation, the only supported, concrete guidance is:

• Flex Consumption is compatible with CI/CD using GitHub Actions and Azure CLI zip deployment.
• Use a workflow that builds the Functions app, creates a .zip, and deploys via az functionapp deployment source config-zip or the Azure Functions GitHub Action.

References:

• Create and manage function apps in the Flex Consumption plan (programming-language-javascript)
• Create and manage function apps in the Flex Consumption plan (programming-language-powershell)
• Continuous delivery by using GitHub Actions (method-cli)
• Continuous delivery by using GitHub Actions (method-manual)
• Continuous delivery by using GitHub Actions (method-template)
• Continuous deployment for Azure Functions