Azure App Service Linux startup.sh not found after SKU upgrade to PremiumV3 despite successful Azure DevOps deployment

Question

Azure App Service Linux startup.sh not found after SKU upgrade to PremiumV3 despite successful Azure DevOps deployment

Jorge Ortiz Flores 0 Microsoft Employee

After upgrading our Azure App Service SKU to PremiumV3/P0v3, the app began failing during startup.

The Azure DevOps deployment completes successfully, but the App Service log stream shows:

Site's appCommandLine: sh startup.shsh: 0: cannot open startup.sh: No such file

The startup.sh file exists in the repository root, and there were no relevant code or YAML changes before this started happening.

Current setup:

App Service: Linux
Runtime: PYTHON|3.11
Deployment: Azure DevOps, AzureWebApp@1
Startup command: sh startup.sh
Deployment method: runFromPackage
SCM_DO_BUILD_DURING_DEPLOYMENT: 0

This started after the SKU upgrade/restart, so I’m trying to understand whether the runtime package mount, startup working directory, or startup command behavior changed.

Main question:

Why would App Service fail to find startup.sh after a successful deployment and SKU upgrade, even though the file exists in the repo?

Siddhesh Desai 7,730 Reputation points Microsoft External Staff Moderator

2026-07-17T20:50:39.5566667+00:00
Hi @Jorge Ortiz Flores

Thank you for reaching out to Microsoft Q&A.

The most likely cause is not the PremiumV3/P0v3 SKU upgrade itself, but rather that after the restart/redeployment, the App Service runtime was unable to locate startup.sh in the actual deployed content mounted under the application root. The error:

Site's appCommandLine: sh startup.sh2sh: 0: cannot open startup.sh: No such file

indicates that the startup command is being executed successfully, but the file cannot be found in the runtime filesystem. Microsoft documentation states that for Linux Python applications, startup commands and startup files must be resolved relative to the deployed project root, and a successful deployment does not necessarily guarantee that the startup file is present within the runtime package.

Additionally, your configuration shows:

WEBSITE_RUN_FROM_PACKAGE = 12 SCM_DO_BUILD_DURING_DEPLOYMENT = 0 Runtime = PYTHON|3.11

For Python applications, Microsoft documents that Run From Package is not supported in the same way as other runtimes unless build automation is enabled, because App Service needs to create the Python environment and install dependencies during deployment. If the ZIP package being deployed does not contain startup.sh at the package root, or if the package structure changed, the mounted runtime content may not match the repository layout and the startup script will not be available at startup.

Refer below points to troubleshoot the issue:

Verify the deployed package contents by connecting to the App Service via SSH/Kudu and confirming whether startup.sh exists under:

/home/site/wwwroot

If the file is missing there, the deployment artifact does not contain it even though it exists in the repository.

Confirm the ZIP artifact structure. When using ZIP deployment or Run From Package, the ZIP must contain application files directly at the root level and not inside an additional parent folder.

Review the Azure DevOps build artifact and verify that startup.sh is included in the published package.

Check whether the startup command should reference a relative subfolder path instead of:

sh startup.sh

if the script is being packaged into a different directory.

If this is a Python application, consider enabling:

SCM_DO_BUILD_DURING_DEPLOYMENT = 1

and redeploying so App Service/Oryx can build the Python environment correctly. Microsoft documentation specifically recommends build automation for Python ZIP deployments.

Compare the value of

WEBSITE_RUN_FROM_PACKAGE

before and after the SKU upgrade. The upgrade itself does not change startup command behavior, but the restart can expose an underlying packaging issue that was previously unnoticed.

In summary: the PremiumV3 upgrade is unlikely to have changed how startup commands are executed. The evidence points to a deployment/package layout issue where startup.sh is not present in the mounted runtime content (/home/site/wwwroot) or is not located at the path expected by the startup command. The first validation step is to SSH into the App Service and verify whether startup.sh actually exists in the deployed runtime filesystem

1 answer

Your answer

Answer 1

The most likely cause is that App Service is starting with sh startup.sh, but the file is not present in the deployed runtime content that the app actually starts from, even though it exists in the source repository.

Supported reasons from the documented behavior:

Startup commands must resolve relative to the project root
For Linux Python apps, all commands in a custom startup command or startup command file must use paths relative to the project root folder. If App Service cannot resolve startup.sh from the deployed app root, startup fails with the exact kind of error shown.
A successful deployment pipeline does not guarantee the startup file is in the runtime content
App Service documentation explicitly says that if the expected startup behavior does not occur, verify that the startup command file is deployed to App Service along with the app code. This matches the symptom: deployment succeeded, but the runtime container cannot open startup.sh.
For Python on Linux, App Service falls back to framework detection if the custom startup command fails
App Service ignores errors while processing a custom startup command or file and then continues looking for Django or Flask apps. That means the deployment can appear successful while startup still fails because the custom file is missing or invalid.
The deployed content, not the repo, determines startup
The Python troubleshooting guidance says to use SSH and verify files under site/wwwroot. If the files are not there, the issue is with what was deployed or mounted, not with the repository contents.

Given the current configuration, the practical explanation is:

startup.sh exists in source control.
The package mounted or extracted for the running app does not contain startup.sh at the app root that App Service is using.
After the SKU upgrade/restart, the app restarted against the actual deployed package, exposing that mismatch.

Checks to run:

Verify the file in the running app
Open an SSH session to the app and check whether site/wwwroot/startup.sh exists. The guidance for Python App Service specifically recommends verifying files under site/wwwroot.
Confirm the deployment artifact layout
Ensure the deployment package places startup.sh in the package root, not inside a subfolder. App Service expects the startup command path relative to the project root.
Review deployment logs
In Azure portal: Deployment Center > Logs > latest Commit ID > Show Logs next to Running oryx build. These logs can reveal whether expected files were included or whether the dependency/build layout differs from what App Service expects.
Check whether the app is showing the default app or startup failure symptoms
If needed, use Diagnose and solve problems and review Application Logs, Container Crash, and Container Issues.
If the file is missing from site/wwwroot, correct the deployment package
The Kudu publish behavior for startup artifacts shows that startup scripts on Linux are expected under home/site/wwwroot/startup.sh by default when deployed as a startup artifact. If the package or deployment task is not placing the file there, App Service will not find it.

What this means for the root cause:

The SKU upgrade itself is not documented as changing startup command semantics.
The documented failure mode is consistent with the startup script not being present at the deployed app root or not being referenced with the correct relative path.
Since SCM_DO_BUILD_DURING_DEPLOYMENT is 0, there is no build step correcting package layout during deployment, so App Service starts only from what was packaged and deployed.