Setting up a Web App. I deploy the example code and it works. I deploy my own code and the web app breaks. I revert back to the example code and the web app is STILL broken. What is going on here?

Question

Setting up a Web App. I deploy the example code and it works. I deploy my own code and the web app breaks. I revert back to the example code and the web app is STILL broken. What is going on here?

Tyler Suard 55

Hello. I am following the Python fastapi example for a web app. I was able to get the app up and running by deploying the example code from Github using CI/CD. Then I modified the code to add my own functions. The web app stopped working completely, it won't even load anymore. So I rolled back to the original example code, and the web app still won't work. What is going on here? If I rolled back to the exact code that worked before, why is the web app no longer working? What did my code do that messed the web app up? Thank you for your help.

RAMAMURTHY MAKARAPU 1,130 Reputation points Microsoft External Staff Moderator

2025-11-11T00:21:44.6766667+00:00
Hi @Tyler Suard ,

Thank you for submitting your question on Microsoft Q&A.

Rolling back code doesn’t always fix everything, because it doesn’t reset the runtime environment your app depends on. Even small changes renaming a module, updating requirements.txt, modifying the startup command, or accidentally switching Python versions or packages can break the app. And when you roll back the repo, those environment-level changes stay in place, because App Service keeps app settings and the built environment (packages, startup commands, container image) separate from your code.
Below is a practical, Azure‑specific checklist to get you back up quickly, plus how to find the root cause.
These common Azure App Service behaviors might be the reasons why the app still fails even after a rollback

Startup command and app entry mismatch

Azure Linux App Service doesn’t “auto-detect” FastAPI reliably once you override the startup command (or if Oryx detection fails). If you renamed your file (e.g., from main.py to app.py) or changed the ASGI variable name (not app), the old startup command like gunicorn -k uvicorn.workers.UvicornWorker main:app will now 404/crash. Rolling the code back doesn’t roll back the App Settings > Startup Command.

Packages/environment drift

If requirements.txt changed (added/removed packages, different versions), the build installed new site-packages. Rolling back code doesn’t necessarily uninstall the now-incompatible versions. Oryx (the App Service build engine) caches/restores environments. If the build didn’t run cleanly (e.g., SCM_DO_BUILD_DURING_DEPLOYMENT off), your site might be running with a mixed package set.

Python version mismatch

Changing PYTHON_VERSION in App Settings or in your GitHub Actions could move you from 3.10 to 3.12 some wheels/extensions differ by Python version.

App settings are “sticky” and not part of your repo

Things like WEBSITE_RUN_FROM_PACKAGE, SCM_DO_BUILD_DURING_DEPLOYMENT, WEBSITE_STARTUP_FILE, STARTUP_COMMAND, WEBSITES_PORT, PYTHON_VERSION, environment variables your code uses—these persist across deploys. If your app now expects new env vars and you removed them from code but left settings invalid (e.g., pointing to non-existent secrets), the app can fail at import time.

Container image drift (if you used a container)

If you built/tagged :latest or referenced a public image tag that moved, you might now be pulling a different image than before—even after code rollback.

Filesystem mode / run-from-package

With WEBSITE_RUN_FROM_PACKAGE=1, the filesystem is read-only. If your code tries to write under /home/site/wwwroot, it’ll crash. Maybe you added a cache, temp file, or SQLite DB in your code path; rolling back may leave a setting or file path change in place.

Fast path to get the app back online: -

Follow these steps in order each one is safe to try and can help quickly restore the app. These instructions assume you are using Azure App Service Linux with CI/CD.

Verify the entry point and port

Go to App Service > Configuration > General settings and check the following:

Stack: Python

Python version: Make sure it's the same version the app was using back when it worked (for example, Python 3.10). If you’re not sure which version was used, choose 3.10, as it’s a stable version that works for many libraries.

Next, open in the same App Service > Configuration open the Application settings and verify:

Startup Command: Remove any custom startup command temporarily. If your app needs one, make sure it's written correctly an incorrect command is a very common cause of failed startups.

WEBSITES_PORT: Ensure this setting exists and is set to 8000. Azure App Service (Linux) expects your application to listen on port 8000 internally, even if you expose a different port externally. This mismatch often causes the app to appear “running” but unreachable.

Startup Command :

If your app module is main.py and the variable is app

gunicorn -k uvicorn.workers.UvicornWorker -w 1 -b 0.0.0.0:8000 main:app

If your ASGI var is not named app, change it or update the command to module:variable. Then restart the app after saving.

Force a clean build of dependencies

If you deploy via GitHub Actions or Azure DevOps: Ensure SCM_DO_BUILD_DURING_DEPLOYMENT=true . Commit a no-op change to trigger a fresh build and redeploy.

If it still fails: Add ORYX_DISABLE_TELEMETRY=true (no functional impact, just cleaner logs). If you can afford it, blow away the cached virtualenv to avoid “mixed” packages: In SSH (App Service → SSH), delete /antenv and /home/site/wwwroot/antenv if present, then redeploy to let Oryx recreate it. Alternatively, temporarily set ENABLE_ORYX_BUILD=true and redeploy.

Verify you’re listening on the right interface/port

Your code or gunicorn must bind to 0.0.0.0:8000. If you ran uvicorn directly in code

uvicorn.run(app, host="0.0.0.0", port=8000)

If you use Gunicorn (recommended for production), rely on the Startup Command above

me.

Turn on logs and see the first failure

App Service > Log stream: watch Application and Web Server logs during a restart.

App Service > Diagnose and solve problems > Availability and Performance will often flag import errors, bad startup commands, or Python crashes.

Kudu / SCM (https://<yourapp>.scm.azurewebsites.net):

Debug console > LogFiles > check gunicorn, default_docker.log, eventlog.xml, startup.txt.

If you see ModuleNotFoundError or AttributeError: module has no attribute 'app', the entrypoint is wrong or a package didn’t install.

Sanity-check your repo for these landmines

requirements.txt: Pin versions where possible; avoid accidental upgrades. If you rolled back, make sure the file truly matches the commit that last worked.

If you added packages like python-multipart, pydantic>=2, or changed FastAPI versions, mismatches can break imports.

File names & ASGI variable: Ensure the file you expect (e.g., main.py) exists at the repo root (or adjust the command to subfolders, e.g., src.main:app). Ensure the FastAPI instance is actually named app, not application or something else (or change the startup command).

Environment variables : If your new code introduced config reads (e.g., os.environ["X"]) and those are still present, they can crash at import time even after “rollback” if you didn’t remove all references. Use os.getenv("X") with defaults or try/except during import.

Reference:

https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/faqs-app-service-linux#my-web-app-still-uses-an-old-docker-container-image-after-i%27ve-updated-the-image-on-docker-hub-do-you-support-continuous-integration-and-deployment-of-custom-containers

https://learn.microsoft.com/en-us/azure/app-service/tutorial-python-postgresql-app-fastapi?tabs=windows&pivots=azure-portal#3-deploy-sample-code

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
RAMAMURTHY MAKARAPU 1,130 Reputation points Microsoft External Staff Moderator

2025-11-12T00:36:51.69+00:00

Hi @Tyler Suard ,

Could you please review my comments, follow the steps, and let me know whether your issue has been resolved?
Shree Hima Bindu Maganti 6,200 Reputation points Microsoft External Staff Moderator

2025-12-15T05:05:24.7+00:00

Hi @Tyler Suard ,
This usually happens because the issue is not with the source code anymore, but with the runtime state of the App Service that was changed when you deployed your custom code. When you modified and deployed your own FastAPI code, it likely introduced a startup failure (for example: missing dependency in requirements.txt, incorrect startup command, incompatible Python version, or a blocking import error). Once this happens, Azure may cache the broken environment, keep failed workers running, or persist incorrect settings, so simply reverting the code does not reset the app back to a healthy state. In many cases, the fix is to restart the App Service, or fully redeploy after cleaning up by checking the startup command, confirming the Python version matches the example, validating requirements.txt, and reviewing logs in Log stream / Application logs. Several users have reported that once the App Service was restarted or redeployed cleanly, the original sample code started working again confirming the issue was due to the app getting into a bad state rather than the rollback code itself.
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs
https://learn.microsoft.com/en-us/azure/app-service/quickstart-python?tabs=flask%2Cwindows%2Cazure-cli%2Cazure-cli-deploy%2Cdeploy-instructions-azportal%2Cterminal-bash%2Cdeploy-instructions-zip-azcli

1 answer

Your answer

RAMAMURTHY MAKARAPU 1,130 Reputation points Microsoft External Staff Moderator

2025-11-12T00:36:51.69+00:00

Hi @Tyler Suard ,

Could you please review my comments, follow the steps, and let me know whether your issue has been resolved?
Shree Hima Bindu Maganti 6,200 Reputation points Microsoft External Staff Moderator

2025-12-15T05:05:24.7+00:00

Hi @Tyler Suard ,
This usually happens because the issue is not with the source code anymore, but with the runtime state of the App Service that was changed when you deployed your custom code. When you modified and deployed your own FastAPI code, it likely introduced a startup failure (for example: missing dependency in requirements.txt, incorrect startup command, incompatible Python version, or a blocking import error). Once this happens, Azure may cache the broken environment, keep failed workers running, or persist incorrect settings, so simply reverting the code does not reset the app back to a healthy state. In many cases, the fix is to restart the App Service, or fully redeploy after cleaning up by checking the startup command, confirming the Python version matches the example, validating requirements.txt, and reviewing logs in Log stream / Application logs. Several users have reported that once the App Service was restarted or redeployed cleanly, the original sample code started working again confirming the issue was due to the app getting into a bad state rather than the rollback code itself.
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs
https://learn.microsoft.com/en-us/azure/app-service/quickstart-python?tabs=flask%2Cwindows%2Cazure-cli%2Cazure-cli-deploy%2Cdeploy-instructions-azportal%2Cterminal-bash%2Cdeploy-instructions-zip-azcli

Answer 1

There could be several reasons why your web app is still broken even after reverting to the original example code. Here are a few possibilities to consider:

Environment Issues: Changes in the environment settings or dependencies might have occurred when you deployed your own code. Ensure that the environment is configured correctly and that all necessary dependencies are installed as per the original example.
Cache or State: Sometimes, the application state or cache might not reset properly when you revert to the original code. You might want to clear any caches or reset the application state if possible.
Configuration Changes: If you made any changes to the configuration settings (like app settings or connection strings) while deploying your own code, those changes might still be in effect. Double-check the configuration settings to ensure they match those of the original example.
Deployment Logs: Check the deployment logs for any errors or warnings that might indicate what went wrong during the deployment of your own code and after reverting. This can provide insights into what might be causing the issue.
Container Issues: If you are using a custom container, ensure that the container image is correctly updated and that there are no issues with the image itself. You might need to refresh the container if it's still using an old version.

If you continue to face issues, consider reviewing the troubleshooting guide for Azure App Service, which can provide more specific guidance on resolving deployment problems.

References:

Tyler Suard 55 Reputation points

2025-11-07T04:13:14.5133333+00:00

How do I reset the caches? There are no errors in the deployment logs.

Share via

Setting up a Web App. I deploy the example code and it works. I deploy my own code and the web app breaks. I revert back to the example code and the web app is STILL broken. What is going on here?

1 answer

Your answer