Python app not running in azure app service

Question

I have built and deployed my python app to Azure app service.

I have disabled SCM_DO_BUILD_DURING_DEPLOYMENT.

The log stream gets stuck on this and no progress at all.

2025-10-28T19:22:55.052346884Z  Launching oryx with: create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh -virtualEnvName antenv -defaultApp /opt/defaultsite -userStartupCommand 'uvicorn talkie.main:app --host 0.0.0.0 --port 8000'
2025-10-28T19:22:55.245570004Z  Could not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
2025-10-28T19:22:55.252417554Z  Could not find operation ID in manifest. Generating an operation id...
2025-10-28T19:22:55.252473554Z  Build Operation ID: 127646db-caf1-4685-bccb-0d31ffaa44fe
2025-10-28T19:22:55.425864828Z  Oryx Version: 0.2.20250709.3, Commit: 0cfb8cb7d114b65e539d2f9ccf9804e87b9966ba, ReleaseTagName: 20250709.3
2025-10-28T19:22:55.444194363Z  Writing output script to '/opt/startup/startup.sh'

Answer 1

When the log stops after Oryx writes startup.sh the usual causes are:

Oryx didn’t finish (or wasn’t allowed to) build/install your app dependencies, so the process that runs the startup command never gets a runnable environment;

the App Service startup command is wrong (or not using the $PORT env var); or

you intentionally disabled the automatic build (SCM_DO_BUILD_DURING_DEPLOYMENT=false) but didn’t supply a pre-built app (virtualenv/site packages) — so Oryx has nothing to run.

create-script only generates the platform startup script. If dependency installation / virtualenv creation is required but disabled, the runtime never becomes ready and logs appear to “hang” at that point.

Quick checklist & fixes

Re-enable build-on-deploy (recommended for most cases)

In the Azure Portal → your Web App → Configuration → Application settings set:

   SCM_DO_BUILD_DURING_DEPLOYMENT = true

Then redeploy. This lets Oryx install packages from requirements.txt and create the virtualenv automatically.

If you want to keep SCM_DO_BUILD_DURING_DEPLOYMENT=false (pre-built deployment)

  Pre-build locally and deploy a runnable artifact:
  
        Create and include a virtual environment inside `/home/site/wwwroot/antenv` (or the virtualEnvName you configured).
        
              Ensure `antenv/bin/activate` and installed packages are present on the target. (Note: shipping virtualenvs between different Linux distributions/versions can break binary wheels — building inside the same distro as App Service is safest.)
              
                 Or use the built artifact (wheel, container image, or a zip that already has `site-packages`) and use ZIP or container deployment.
                 
                 **Use the correct startup command and port**
                 
                    Azure App Service passes the port in the environment variable `PORT`. Your startup command must use that:
                    
                    ```yaml
                    uvicorn talkie.main:app --host 0.0.0.0 --port $PORT
                    ```
                    
                    Put this exactly (or set it in Portal → **Configuration** → **General settings** → **Startup Command**). Hardcoding `8000` can fail if the platform expects `$PORT`.
                    
                    **Check the runtime stack / Python version**
                    
                       Portal → **Configuration** → **General settings** → **Stack**. Ensure Python version matches what your app expects and what you built against.
                       
                       **View more logs (Kudu / diagnostic logs) to see what's blocking**
                       
                          Enable detailed logging: Portal → **App Service logs** → enable **Application Logging (Filesystem)** and **Platform logs**.
                          
                             Tail logs with Azure CLI:
                             
                             ```dockerfile
                             az webapp log tail -n <appName> -g <rg>
                             ```
                             
                                Check Kudu/SSH (Advanced Tools):
                                
                                      Go to **Development Tools > Advanced Tools (Kudu)** → **Debug console** → look inside `/home/site/wwwroot` and `/home/LogFiles` for oryx/diagnostic logs.
                                      
                                            Check `/home/LogFiles/oryx/*` and `/home/LogFiles/docker/*` and `/home/LogFiles/Application/*.log`.
                                            
                                            **Inspect the generated startup script**
                                            
                                               Use Kudu debug console to open `/opt/startup/startup.sh` (or the script Oryx wrote). Confirm it’s invoking the right virtualenv and startup command. If it references a missing virtualenv, that explains the hang.
                                               
                                               **If dependency install is the blocker**
                                               
                                                  If `pip install` is taking too long or stuck (large wheels or private indexes), either:
                                                  
                                                        Let Oryx run builds (enable SCM build), or
                                                        
                                                              Pre-build wheels and vendor them, or
                                                              
                                                                    Make sure your `requirements.txt` contains only what you need and there is no interactive prompt (e.g., private package auth).
                                                                    

1. For repeated deployment issues: prefer containerization
   • If reproducible environment matters, containerize the app (Docker) and deploy to App Service for Linux as a container — you control the full runtime and nothing relies on Oryx.When the log stops after Oryx writes startup.sh the usual causes are:
   • Oryx didn’t finish (or wasn’t allowed to) build/install your app dependencies, so the process that runs the startup command never gets a runnable environment;
   • the App Service startup command is wrong (or not using the $PORT env var); or
   • you intentionally disabled the automatic build (SCM_DO_BUILD_DURING_DEPLOYMENT=false) but didn’t supply a pre-built app (virtualenv/site packages) — so Oryx has nothing to run.
   create-script only generates the platform startup script. If dependency installation / virtualenv creation is required but disabled, the runtime never becomes ready and logs appear to “hang” at that point. Quick checklist & fixes
   1. Re-enable build-on-deploy (recommended for most cases)
      • In the Azure Portal → your Web App → Configuration → Application settings set:

                   SCM_DO_BUILD_DURING_DEPLOYMENT
        

        Then redeploy. This lets Oryx install packages from requirements.txt and create the virtualenv automatically.
   2. If you want to keep SCM_DO_BUILD_DURING_DEPLOYMENT=false (pre-built deployment)
      • Pre-build locally and deploy a runnable artifact:
      • Create and include a virtual environment inside /home/site/wwwroot/antenv (or the virtualEnvName you configured).
      • Ensure antenv/bin/activate and installed packages are present on the target. (Note: shipping virtualenvs between different Linux distributions/versions can break binary wheels — building inside the same distro as App Service is safest.)
      • Or use the built artifact (wheel, container image, or a zip that already has site-packages) and use ZIP or container deployment.
   3. Use the correct startup command and port
      • Azure App Service passes the port in the environment variable PORT. Your startup command must use that:

                   uvicorn
        

        Put this exactly (or set it in Portal → Configuration → General settings → Startup Command). Hardcoding 8000 can fail if the platform expects $PORT.
   4. Check the runtime stack / Python version
      • Portal → Configuration → General settings → Stack. Ensure Python version matches what your app expects and what you built against.
   5. View more logs (Kudu / diagnostic logs) to see what's blocking
      • Enable detailed logging: Portal → App Service logs → enable Application Logging (Filesystem) and Platform logs.
      • Tail logs with Azure CLI:

                   az webapp 
        

      • Check Kudu/SSH (Advanced Tools):
      • Go to Development Tools > Advanced Tools (Kudu) → Debug console → look inside /home/site/wwwroot and /home/LogFiles for oryx/diagnostic logs.
      • Check /home/LogFiles/oryx/* and /home/LogFiles/docker/* and /home/LogFiles/Application/*.log.
   6. Inspect the generated startup script
      • Use Kudu debug console to open /opt/startup/startup.sh (or the script Oryx wrote). Confirm it’s invoking the right virtualenv and startup command. If it references a missing virtualenv, that explains the hang.
   7. If dependency install is the blocker
      • If pip install is taking too long or stuck (large wheels or private indexes), either:
      • Let Oryx run builds (enable SCM build), or
      • Pre-build wheels and vendor them, or
      • Make sure your requirements.txt contains only what you need and there is no interactive prompt (e.g., private package auth).
   8. For repeated deployment issues: prefer containerization
      • If reproducible environment matters, containerize the app (Docker) and deploy to App Service for Linux as a container — you control the full runtime and nothing relies on Oryx.