Azure Linux Function App: Should old deployment ZIPs in /home/data/SitePackages be cleaned up?

Question

Hello all,

We have a Python Azure Function App running on Linux and are reviewing how deployment packages are managed when using Run From Package.

Our Azure DevOps pipeline deploys a ZIP artifact to the Function App. With Run From Package enabled, deployment ZIP files are stored under:

/home/data/SitePackages/

We can see multiple deployment ZIP files remaining in this directory from previous deployments.

From the Microsoft documentation, my understanding is that when WEBSITE_RUN_FROM_PACKAGE=1 is used on Linux, Azure Functions stores the deployment package in /home/data/SitePackages and runs the application from the package. Run your Functions from a Package File in Azure [learn.microsoft.com]

I would like to understand how this directory is intended to be managed.

Questions:

• Is /home/data/SitePackages fully managed by Azure Functions/Kudu, or is the customer expected to clean it periodically?
• Is it normal and expected for ZIP files from previous deployments to remain in /home/data/SitePackages?
• Does Azure Functions automatically remove older deployment ZIPs from this directory at some point?
• Is there a documented retention policy or maximum number of deployment packages that Azure keeps in /home/data/SitePackages?
• Is there any risk of potential threats if old packages which are vulnerable remain on this location?
• Should we avoid manually deleting old ZIP files from /home/data/SitePackages?
• Is it recommended to clean this directory before each deployment, or should Azure Functions be allowed to manage it completely?

Thanks.

Answer 1

Do not clean /home/data/SitePackages before each deployment; leave the directory under the deployment service’s control, and never delete packagename.txt or the ZIP file it identifies as active.

Expected behavior

For a Linux Function App on a Premium or Dedicated plan with WEBSITE_RUN_FROM_PACKAGE=1:

• ZIP deployment stores the package in /home/data/SitePackages.
• packagename.txt contains the name of the package that the runtime mounts.
• That selected ZIP is mounted as the read-only wwwroot.
• Other timestamp-named ZIP files are inactive deployment artifacts; their presence does not cause them to execute. ^1^

Therefore, seeing several ZIP files alongside packagename.txt, as in the screenshot, is not by itself an error.

You can identify the active package without changing anything:

cd /home/data/SitePackages
active="$(tr -d '\r\n' < packagename.txt)"
printf 'Active package: %s\n' "$active"
test -f "$active" && echo "Active package exists" ||
  echo "ERROR: Active package is missing"

Retention and cleanup

Microsoft’s public deployment documentation does not specify a supported age-based retention period, fixed maximum package count, or schedule for inactive ZIPs in SitePackages. Consequently:

• Do not assume old ZIPs will disappear after a particular number of days.
• Do not build capacity or rollback procedures around an observed number such as five packages.
• Multiple packages may remain after deployments.
• Any platform pruning behavior should be treated as an implementation detail, not a retention guarantee.

The documentation’s statement that ZIP deployment deletes files from previous deployments concerns deployment content management; it does not document a retention contract for package archives in SitePackages. ^1^

Manual deletion

Routine manual deletion is not recommended because deleting the package named by packagename.txt leaves the runtime pointing to a missing package and can prevent the application from mounting or starting. The package and selector file together form the active deployment state. App Service documents that packagename.txt identifies the ZIP loaded at runtime. ^2^

If accumulated packages create an actual storage-capacity problem:

1. Stop automated deployments temporarily so cleanup cannot race with a deployment.
2. Read packagename.txt.
3. Verify that the named ZIP exists.
4. Preserve both packagename.txt and that active ZIP.
5. Preserve any inactive package required by your own rollback process.
6. Delete only confirmed inactive *.zip files.
7. Restart the app and verify host startup and representative functions.

This is an operational workaround rather than a documented Azure retention procedure. For production automation, open an Azure support request to confirm the behavior for the app’s hosting plan and deployment task before adding deletion logic to the pipeline.

Security implications

Only the ZIP selected by packagename.txt is mounted and executed, so an inactive package containing vulnerable dependencies is not an additional running copy of the application. It should still be treated as a sensitive deployment artifact because it may contain source code, binaries, or configuration accidentally included during packaging.

Apply normal controls:

• Restrict Azure RBAC and SCM/Kudu access.
• Do not package secrets or local configuration files.
• Keep the active deployment patched.
• Remove inactive artifacts when required by an organizational data-retention policy, using the guarded procedure above.

Confirm the hosting plan

WEBSITE_RUN_FROM_PACKAGE=1 with local /home/data/SitePackages is documented for Linux Premium and Dedicated Function Apps. Linux Consumption uses remote build or an external package URL, while Flex Consumption uses managed package deployment and should not set WEBSITE_RUN_FROM_PACKAGE. ^1^

If this app is Linux Consumption or Flex Consumption, the current configuration should be reviewed rather than treating this directory as the supported package-management model.

---

References

1. Package-based deployment for Azure Functions | Microsoft Learn
2. Run Your App from a ZIP Package - Azure App Service

Answer 2

For WEBSITE_RUN_FROM_PACKAGE=1, do not delete the contents of /home/data/SitePackages before each deployment.

When Zip Deploy is used with Run From Package, the deployment ZIP is copied to /home/data/SitePackages. The deployment process updates packagename.txt, and the ZIP named in that file is mounted as the read-only wwwroot filesystem after the Function App restarts. Therefore, multiple ZIP files in SitePackages do not mean that multiple versions are executing. Only the package selected through packagename.txt is mounted. See Run your Functions from a Package File in Azure. [learn.microsoft.com]

A few important points:

Customer cleanup is not required for normal deployment

Zip Deploy and the Functions platform manage selection of the active package. Wiping SitePackages before deployment introduces unnecessary risk because the currently mounted package may still be required until deployment, restart and trigger synchronisation have completed.

Older ZIP files can remain

Seeing packages from earlier deployments is not, by itself, an error. However, the current Microsoft Functions documentation does not specify a guaranteed cleanup interval, retention period or maximum number of historical ZIP files. The documented 1 GB limit applies to an individual deployment package, not to the retention of previous packages. [learn.microsoft.com]

Do not delete the package named in packagename.txt

Deleting the referenced package can prevent the Function App from starting correctly after a restart or remount. Cleanup performed during a deployment can also race with the update of packagename.txt, particularly when deployment processing is asynchronous. A historical Kudu issue demonstrates that a package upload and successful HTTP response do not necessarily mean that package activation has completed. Deployment status and logs should be checked before any cleanup operation. [github.com]

Old packages are not normally executed

An inactive ZIP does not become executable merely because it remains in SitePackages. The immediate runtime risk is therefore low, provided that:

• it is not referenced by packagename.txt;
  • SCM/Kudu access is restricted;
    • deployment credentials are protected; and
      • access to the app's persistent filesystem is controlled.
      There can still be a data-retention risk if an old package contains credentials, certificates, configuration files, proprietary source code or vulnerable dependencies. Secrets should not be embedded in deployment packages in the first place. Use Function App settings, managed identities and Azure Key Vault for sensitive configuration. Controlled cleanup is optional, not a standard pre-deployment step If storage, security or compliance requirements require retention control, perform cleanup only after:

      - the new deployment reports success;
      
         - `packagename.txt` references the expected new ZIP;
      
            - the Function App has restarted successfully;
      
               - triggers have been synchronised; and
      
                  - application health checks have passed.
      
                  The cleanup process must exclude `packagename.txt`, its referenced ZIP and any package deliberately retained for operational rollback. It should also be serialised with deployments so that cleanup and deployment cannot run concurrently.
      
                  Check the hosting plan
      
                  `WEBSITE_RUN_FROM_PACKAGE=1` is appropriate for Linux Elastic Premium and Dedicated plans. For a Linux Function App on the classic Consumption plan, Microsoft documents that Run From Package must use a package URL rather than the local `1` setting. Flex Consumption runs from a package by default and should not have `WEBSITE_RUN_FROM_PACKAGE` added manually. [[learn.microsoft.com]](https://learn.microsoft.com/hi-in/azure/azure-functions/run-functions-from-deployment-package)
      

Bottom line: Allow Zip Deploy and Azure Functions to manage the active package. Do not add an unconditional command such as rm /home/data/SitePackages/*.zip to the Azure DevOps pipeline. If retention is required, use a post-deployment cleanup process that first verifies the active package and application health, then removes only confirmed inactive packages.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution