-
Notifications
You must be signed in to change notification settings - Fork 653
Understanding the Azure App Service file system
See also this page with related information.
There are three main types of files that an Azure Web App can deal with
This is what you can view as your web site's files. They follow a structure described here. They are rooted in %HOME% directory. For App Service on Linux and Web app for Containers, persistent storage is rooted in /home.
These files are persistent, meaning that you can rely on them staying there until you do something to change them. Also, they are shared between all instances of your site (when you scale it up to multiple instances). Internally, the way this works is that they are stored in Azure Storage instead of living on the local file system.
Free and Shared sites get 1GB of space, Basic sites get 10GB, and Standard sites get 50GB. See more details on the Web App Pricing page.
A number of common Windows locations are using temporary storage on the local machine. For instance,
-
%APPDATA%maps to%SYSTEMDRIVE%\local\AppData. -
%ProgramData%maps to%SYSTEMDRIVE%\local\ProgramData. -
%TMP%maps to%SYSTEMDRIVE%\local\Temp. -
%SYSTEMDRIVE%\local\DynamicCachefor Dynamic Cache feature.
Unlike Persisted files, these files are not shared among site instances. Also, you cannot rely on them staying there. For instance, if you restart a web app, you'll find that all of these folders get reset to their original state.
For Free, Shared and Consumption (Functions) sites, there is a 500MB limit for all these locations together (i.e. not per-folder).
For Standard and Basic sites, the limit is higher and differs depending on the SKU. The limit applies to all sites in the same App Service Plan. For instance, if you have 10 sites in S2 App Service Plan, those sites (and their scm sites) will have a combined limit of 15 GB. This same limit is applied on each VM instance - not a shared limit combined across instances.
See limit for other SKU below.
| SKU Family | B1/S1/etc. | B2/S2/etc. | B3/S3/etc. |
|---|---|---|---|
| Basic, Standard, Premium | 11 GB | 15 GB | 58 GB |
| PremiumV2, Isolated | 21 GB | 61 GB | 140 GB |
Another important note is that the Main site and the scm site do not share temp files. So if you write some files there from your site, you will not see them from Kudu Console (and vice versa). You can make them use the same temp space if you disable separation (via WEBSITE_DISABLE_SCM_SEPARATION). But note that this is a legacy flag, and its use is not recommended/supported.
You can check your limit and usage in portal by going to "Diagnose and solve problems" section of your App Service blade, selecting "Best Practices", "Best Practices for Availability, Performance", and then "Temp File Usage On Workers". Please note that the displayed usage and limits are per worker, and are aggregated across all apps in the same app service plan.
The best practice is to not hardcode any drive letter and instead of using paths like d:\home in the code use rather %HOME% (or %SystemDrive% if just the root path is needed). The environment variables will be always set correctly.
On subset of App Service instances the environment variables might resolve to D: paths (typically apps deployed in the past), on others they might resolve to C: paths (typically new apps). As underlying improvements and maintenances are performed, apps will be automatically shifted to architecture which will have C: drive as the OS drive, thus %HOME% (and %SystemDrive%) will resolve to C: paths as well. To ensure backward compatibility, when the OS drive becomes C: drive, there is still mapping from D: to C: as well, so any apps which had D: paths hardcoded will still work correctly.
The Web App is able to access many standard Windows locations like %ProgramFiles% and %windir%. These files can never be modified by the Web App.