Logic App Standard with Private Endpoints – Local Functions Not Working with Run From Package

Question

Logic App Standard with Private Endpoints – Local Functions Not Working with Run From Package

Sumit Gaur 475

Hi Team,

We are running a private Logic App Standard along with a private Storage Account. The Logic App is VNET-integrated, and all four Storage Account services have private endpoints configured. Outbound traffic from the Logic App is also configured to route through the VNET.

We are observing an issue specifically with Logic Apps that contain local functions in this configuration.

When we configure the CI/CD pipeline to use runFromPackage deployment mode and set the following application setting:

WEBSITE_RUN_FROM_PACKAGE=1

The local functions in the Logic App stop working. We have also noticed that, with this configuration, the wwwroot folder containing the Logic App code/content is not visible in the Kudu console under the site directory.

However, when we remove the WEBSITE_RUN_FROM_PACKAGE application setting and change the CI/CD deployment mode back to zipDeploy, the Logic App and its local functions start working again, and the wwwroot content is available as expected.

The same logic app works when both logic app standard and storage account has inbound access as public and running on runFromPackage mode.

Can you help in determining if we need to configure any additional private endpoints or need to add any additional app setting?

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-09T11:30:33.3+00:00
Hi @Sumit Gaur ,

Based on the behavior you described, the issue appears to be related to WEBSITE_RUN_FROM_PACKAGE=1 rather than a missing Private Endpoint.

When this setting is enabled, the Logic App runs from a read-only deployment package instead of using the Azure Files content share in the usual way. This can prevent Local Functions from being loaded correctly.

This also matches your testing, where:

Removing WEBSITE_RUN_FROM_PACKAGE=1 restores the Local Function.

Deploying through Zip Deploy restores the expected wwwroot content and functionality.

Recommended action

As a workaround, please:

Remove WEBSITE_RUN_FROM_PACKAGE=1.

Use Zip Deploy to deploy the Logic App.

Verify that WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE are configured correctly.

Restart the Logic App after making the changes.

If the issue still occurs after these changes, please share the Logic App configuration and the relevant deployment/runtime logs so we can investigate further.

Based on the current evidence, we do not see an indication that an additional Private Endpoint is required specifically for Local Functions.
Sumit Gaur 475 Reputation points

2026-08-09T15:13:32.9033333+00:00

Hi @Likhitha Sulake

i don't think this is specific to run from package app setting as we have other logic app as well which have the same setting but have public access enabled on both logic app standard and azure storage account but there we don't see the issue. the wwwroot folder is visible in the kudu console.

hence i am thinking that only thing that changed between the two logic app is just that one is fully private while other is fully public.
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-10T10:07:38.36+00:00
Hi @Sumit Gaur ,

Since the Logic App works with WEBSITE_RUN_FROM_PACKAGE=1 when public access is enabled, the issue appears to be related to the private networking/storage connectivity rather than the Run-From-Package setting itself.

Could you please verify the following:

Confirm private endpoints are configured for Blob, File, Queue, and Table on the Storage Account.

Verify that the Logic App can resolve the Storage Account endpoints to the correct private IP addresses through Private DNS.

Confirm the Logic App has network connectivity to the Storage Account through the VNet.

Check the following settings:

AzureWebJobsStorage

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

WEBSITE_CONTENTSHARE

Review the Logic App/Kudu logs for any storage mount, package mount, DNS, or connectivity errors during startup.

At this point, we don't have evidence that an additional private endpoint is required. The key difference is that the issue occurs only when the Storage Account is accessed privately.

Please share the Storage Account networking settings, Private DNS configuration, relevant app settings, and any startup errors you find. This will help us identify where the connection is failing.

Sumit Gaur 475

Hi @Likhitha Sulake both tcpping and nameresovler works on all of storage endpoints, it is able to connect and correct resolve DNS to private endpoint IP. the issue is only with those logic app where we have local functions, the logic app used with built in connectors works fine even though wwwroot not being visible in kudu console.

below are tcpping and nameresolver screenshot and all needed app setting we have.

User's image

[
    {
        "name": "APP_KIND",
        "value": "workflowApp",
        "slotSetting": false
    },
    {
        "name": "AzureFunctionsJobHost__extensionBundle__id",
        "value": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
        "slotSetting": false
    },
    {
        "name": "AzureWebJobsStorage",
        "value": "<SENSITIVE_VALUE>",
        "slotSetting": false
    },
    {
        "name": "AzureFunctionsJobHost__extensionBundle__version",
        "value": "[1.*, 2.0.0)",
        "slotSetting": false
    },
    {
        "name": "FUNCTIONS_EXTENSION_VERSION",
        "value": "~4",
        "slotSetting": false
    },
    {
        "name": "FUNCTIONS_WORKER_RUNTIME",
        "value": "dotnet",
        "slotSetting": false
    },
    {
        "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
        "value": "<SENSITIVE_VALUE>",
        "slotSetting": false
    },
    {
        "name": "WEBSITE_CONTENTOVERVNET",
        "value": "1",
        "slotSetting": false
    },
    {
        "name": "WEBSITE_CONTENTSHARE",
        "value": "<SENSITIVE_VALUE>",
        "slotSetting": false
    },
    {
        "name": "WEBSITE_ENABLE_SYNC_UPDATE_SITE",
        "value": "1",
        "slotSetting": false
    },
    {
        "name": "WEBSITE_NODE_DEFAULT_VERSION",
        "value": "~22",
        "slotSetting": false
    },
    {
        "name": "WEBSITE_RUN_FROM_PACKAGE",
        "value": "1",
        "slotSetting": false
    },
    {
        "name": "Workflows.RuntimeConfiguration.RetentionInDays",
        "value": "30",
        "slotSetting": false
    }
]

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-12T11:01:47.5533333+00:00

Hi @Sumit Gaur ,
Following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.
Sumit Gaur 475 Reputation points

2026-08-25T16:46:59.98+00:00
Hi @Likhitha Sulake

I have checked but could not find anything odd, one thing what we noticed is though, when we move the app back from zip deploy to run from package it works but not on the first attempt, this is what we have tried.

provisioned a new logic app standard and have the code deployed in run from package mode. with this the local function stopped working.

removed the run from package app setting and deployed the code in the zip deploy method, the local functoin starts working.

redeployed the code now as run from package with which the wwroot becomes visible and local function starts workig,
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-26T12:42:00.6033333+00:00
Hi @Sumit Gaur ,

Thank you for the update. The new observation is very useful. Since a newly provisioned Logic App fails when initially deployed using Run From Package, but starts working after a Zip Deploy followed by another Run From Package deployment, the issue appears less likely to be related to missing Private Endpoints and more likely related to package retrieval, package mounting, or Function host initialization during the first Run From Package deployment.

Could you please collect the following from a fresh reproduction where the first Run From Package deployment fails:

Function host startup/runtime logs

Kudu/Event Logs

Deployment Center logs

Application Insights traces (if enabled)

Any errors under Diagnose and Solve Problems

Confirmation of where the deployment package (.zip) is stored

The exact CI/CD deployment steps used when WEBSITE_RUN_FROM_PACKAGE=1

Since DNS resolution, private endpoint connectivity, and storage access have already been validated, these logs will help determine whether the failure occurs during package retrieval, package mounting, or Local Function host startup. At this point, we still do not have evidence that an additional Private Endpoint is required for this scenario.

3 answers

Your answer

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-09T11:30:33.3+00:00

Hi @Sumit Gaur ,

Based on the behavior you described, the issue appears to be related to WEBSITE_RUN_FROM_PACKAGE=1 rather than a missing Private Endpoint.

When this setting is enabled, the Logic App runs from a read-only deployment package instead of using the Azure Files content share in the usual way. This can prevent Local Functions from being loaded correctly.

This also matches your testing, where:

Removing WEBSITE_RUN_FROM_PACKAGE=1 restores the Local Function.

Deploying through Zip Deploy restores the expected wwwroot content and functionality.

Recommended action

As a workaround, please:

Remove WEBSITE_RUN_FROM_PACKAGE=1.

Use Zip Deploy to deploy the Logic App.

Verify that WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE are configured correctly.

Restart the Logic App after making the changes.

If the issue still occurs after these changes, please share the Logic App configuration and the relevant deployment/runtime logs so we can investigate further.

Based on the current evidence, we do not see an indication that an additional Private Endpoint is required specifically for Local Functions.
Sumit Gaur 475 Reputation points

2026-08-09T15:13:32.9033333+00:00

Hi @Likhitha Sulake

i don't think this is specific to run from package app setting as we have other logic app as well which have the same setting but have public access enabled on both logic app standard and azure storage account but there we don't see the issue. the wwwroot folder is visible in the kudu console.

hence i am thinking that only thing that changed between the two logic app is just that one is fully private while other is fully public.
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-10T10:07:38.36+00:00

Hi @Sumit Gaur ,

Since the Logic App works with WEBSITE_RUN_FROM_PACKAGE=1 when public access is enabled, the issue appears to be related to the private networking/storage connectivity rather than the Run-From-Package setting itself.

Could you please verify the following:

Confirm private endpoints are configured for Blob, File, Queue, and Table on the Storage Account.

Verify that the Logic App can resolve the Storage Account endpoints to the correct private IP addresses through Private DNS.

Confirm the Logic App has network connectivity to the Storage Account through the VNet.

Check the following settings:

AzureWebJobsStorage

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

WEBSITE_CONTENTSHARE

Review the Logic App/Kudu logs for any storage mount, package mount, DNS, or connectivity errors during startup.

At this point, we don't have evidence that an additional private endpoint is required. The key difference is that the issue occurs only when the Storage Account is accessed privately.

Please share the Storage Account networking settings, Private DNS configuration, relevant app settings, and any startup errors you find. This will help us identify where the connection is failing.
Sumit Gaur 475 Reputation points

2026-08-11T12:20:34.42+00:00

Hi @Likhitha Sulake both tcpping and nameresovler works on all of storage endpoints, it is able to connect and correct resolve DNS to private endpoint IP. the issue is only with those logic app where we have local functions, the logic app used with built in connectors works fine even though wwwroot not being visible in kudu console.

below are tcpping and nameresolver screenshot and all needed app setting we have.

[ { "name": "APP_KIND", "value": "workflowApp", "slotSetting": false }, { "name": "AzureFunctionsJobHost__extensionBundle__id", "value": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "slotSetting": false }, { "name": "AzureWebJobsStorage", "value": "<SENSITIVE_VALUE>", "slotSetting": false }, { "name": "AzureFunctionsJobHost__extensionBundle__version", "value": "[1.*, 2.0.0)", "slotSetting": false }, { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4", "slotSetting": false }, { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "dotnet", "slotSetting": false }, { "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING", "value": "<SENSITIVE_VALUE>", "slotSetting": false }, { "name": "WEBSITE_CONTENTOVERVNET", "value": "1", "slotSetting": false }, { "name": "WEBSITE_CONTENTSHARE", "value": "<SENSITIVE_VALUE>", "slotSetting": false }, { "name": "WEBSITE_ENABLE_SYNC_UPDATE_SITE", "value": "1", "slotSetting": false }, { "name": "WEBSITE_NODE_DEFAULT_VERSION", "value": "~22", "slotSetting": false }, { "name": "WEBSITE_RUN_FROM_PACKAGE", "value": "1", "slotSetting": false }, { "name": "Workflows.RuntimeConfiguration.RetentionInDays", "value": "30", "slotSetting": false } ]
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-12T11:01:47.5533333+00:00

Hi @Sumit Gaur ,
Following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.
Sumit Gaur 475 Reputation points

2026-08-25T16:46:59.98+00:00

Hi @Likhitha Sulake

I have checked but could not find anything odd, one thing what we noticed is though, when we move the app back from zip deploy to run from package it works but not on the first attempt, this is what we have tried.

provisioned a new logic app standard and have the code deployed in run from package mode. with this the local function stopped working.

removed the run from package app setting and deployed the code in the zip deploy method, the local functoin starts working.

redeployed the code now as run from package with which the wwroot becomes visible and local function starts workig,
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-26T12:42:00.6033333+00:00

Hi @Sumit Gaur ,

Thank you for the update. The new observation is very useful. Since a newly provisioned Logic App fails when initially deployed using Run From Package, but starts working after a Zip Deploy followed by another Run From Package deployment, the issue appears less likely to be related to missing Private Endpoints and more likely related to package retrieval, package mounting, or Function host initialization during the first Run From Package deployment.

Could you please collect the following from a fresh reproduction where the first Run From Package deployment fails:

Function host startup/runtime logs

Kudu/Event Logs

Deployment Center logs

Application Insights traces (if enabled)

Any errors under Diagnose and Solve Problems

Confirmation of where the deployment package (.zip) is stored

The exact CI/CD deployment steps used when WEBSITE_RUN_FROM_PACKAGE=1

Since DNS resolution, private endpoint connectivity, and storage access have already been validated, these logs will help determine whether the failure occurs during package retrieval, package mounting, or Local Function host startup. At this point, we still do not have evidence that an additional Private Endpoint is required for this scenario.

Answer 1

For a private Azure Logic Apps Standard deployment, the supported guidance in the available documentation is:

Configure private endpoints for all four storage services: Blob, File, Queue, and Table.
Configure Virtual network integration on the logic app.
Route access to workflow data over the VNet by setting WEBSITE_CONTENTOVERVNET = 1.
If custom DNS is used, set WEBSITE_DNS_SERVER and optionally WEBSITE_DNS_ALT_SERVER.
Verify DNS resolution for the storage endpoints returns the private IP addresses.
Verify connectivity from a VM in the same VNet by using nslookup and psping/tcpping.
Check the logic app app settings WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE for correctness.
Run the built-in detectors Logic App Down or Reporting Errors and Network Troubleshooter.
Ensure Allow storage account key access is enabled on the storage account.

The available documentation does not describe any additional private endpoint specifically for local functions or any extra app setting specifically for making local functions work with WEBSITE_RUN_FROM_PACKAGE=1 in this private-endpoint scenario.

Based on the documented configuration, the main settings to verify are:

WEBSITE_CONTENTOVERVNET = 1
WEBSITE_DNS_SERVER and WEBSITE_DNS_ALT_SERVER if custom DNS is used
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
WEBSITE_CONTENTSHARE
WEBSITE_VNET_ROUTE_ALL = 1

Also verify that:

all storage private DNS zones are linked correctly to the integrated VNet
the storage endpoints resolve to private IPs
port connectivity works to Blob/Queue/Table on 443 and File on 445
the storage account still allows key-based access

The behavior described for wwwroot not appearing in Kudu when run from package is enabled is not covered in the provided documentation, and no documented extra private endpoint is listed for that case.

References:

Answer 2

kagiyama yutaka 5,330

I think Logic App Standard loads its workflows and local functions from the Storage content share mounted read‑write at wwwroot, and WEBSITE_RUN_FROM_PACKAGE switches the app to a read‑only ZIP so the content share isn’t used. In that state the runtime can’t load workflows or local functions and Kudu shows an empty wwwroot. Removing that setting and deploying by zip brings back the normal mount, and re‑saving App Settings with a restart helps when the mount looks empty.

0 comments

Answer 3

Hi @Sumit Gaur ,

Thank you for sharing the screenshots and configuration details.

Based on the information provided so far, we understand that:

Private Endpoints are configured for the Blob, File, Queue, and Table services.

DNS resolution is correctly resolving the storage endpoints to their private IP addresses.

Network connectivity to the Storage Account is successful.

Built-in connector workflows continue to function as expected.

The issue appears to be isolated to Local Functions when WEBSITE_RUN_FROM_PACKAGE=1 is enabled in the private networking configuration.

Since the storage connectivity and DNS resolution appear to be functioning correctly, we would like to focus the next stage of troubleshooting on package retrieval/mounting and Local Functions host startup.

Could you please provide the following information from a fresh reproduction?

Runtime/host logs captured during Logic App startup while WEBSITE_RUN_FROM_PACKAGE=1 is enabled.

Any relevant errors reported under Diagnose and Solve Problems for the Logic App.

Application Insights traces, if Application Insights is enabled, particularly those related to:

Function loading

  Package mounting
  
     Host startup
     
        Storage access
        
        Confirmation of where the deployment package (`.zip`) is stored:
        
           In the same private Storage Account, or
           
              In a different Storage Account
              
              The exact deployment method used by the CI/CD pipeline when Run From Package is enabled.
              
              Any errors or warnings visible in:
              
                 Host Status
                 
                    Functions blade
                    
                       Kudu/Event Logs
                       
                          Deployment Center logs

If possible, please reproduce the issue once more with WEBSITE_RUN_FROM_PACKAGE=1 enabled and share the corresponding startup/host logs and timestamps.

These details will help us determine whether the failure is occurring while the package is being retrieved, mounted, or loaded by the Local Functions runtime, and will allow us to narrow down the issue further.