Document Details
Configure Custom Container
❌
This page contains Windows bias
About This Page
This page is part of the Azure documentation. It contains code examples and configuration instructions for working with Azure services.
Bias Analysis
Bias Types:
⚠️
windows_first
⚠️
powershell_heavy
⚠️
windows_tools
⚠️
missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows-specific instructions, tools, and examples (such as PowerShell commands, Windows base images, and Kudu/FTP access patterns) are often presented first or in more detail. Some advanced configuration sections (memory, CPU, health ping) are only described for Windows containers, with no Linux equivalents. While Linux content is present and there are Linux-specific pivots, parity in depth and clarity is lacking in several areas.
Recommendations:
- For every Windows-specific section (e.g., customizing memory, CPU, health ping), provide equivalent Linux container instructions or explicitly state if the feature is not supported for Linux.
- When showing both Bash and PowerShell commands, present Bash (Linux) first or side-by-side, not always after PowerShell.
- Ensure that advanced diagnostic and logging instructions (e.g., Kudu, FTP, log access) are equally detailed for Linux containers, not just Windows.
- In sections about persistent storage, clarify differences and provide equal detail for both platforms, including Linux-specific caveats and best practices.
- Where Windows parent images are listed, provide a similar list or guidance for recommended Linux base images.
- Review all examples and ensure Linux tools and patterns (e.g., SSH, Linux file paths, Docker Compose) are as prominent as Windows ones.
- Explicitly call out any features that are Windows-only, and provide links or alternatives for Linux users where possible.
Create pull request
Scan History
| Date | Scan ID | Status | Bias Status |
|---|---|---|---|
| 2025-09-15 00:00 | #112 | completed | ❌ Biased |
| 2025-08-15 00:01 | #81 | in_progress | ❌ Biased |
| 2025-07-13 21:37 | #48 | completed | ❌ Biased |
| 2025-07-13 21:25 | #47 | cancelled | ✅ Clean |
| 2025-07-13 20:48 | #44 | cancelled | ✅ Clean |
| 2025-07-09 13:09 | #3 | cancelled | ✅ Clean |
| 2025-07-08 04:23 | #2 | cancelled | ❌ Biased |
Flagged Code Snippets
In PowerShell:
In PowerShell:
In PowerShell:
In PowerShell:
In PowerShell:
Replace the following values:
- *\<app-name>* with the name of your web app.
> [!TIP]
> If you use PowerShell console to run the commands, escape the strings in the `--generic-configurations` argument in this step and the next step. For example: `--generic-configurations '{\"acrUseManagedIdentityCreds\": true'`
1. (Optional) If your app uses a [user-assigned managed identity](overview-managed-identity.md#add-a-user-assigned-identity), make sure the identity is configured on the web app and then set the `acrUserManagedIdentityID` property to specify its client ID:
When your app runs, the App Service app settings are injected into the process as environment variables automatically. You can verify container environment variables with the URL `https://<app-name>.scm.azurewebsites.net/Env`.
If your app uses images from a private registry or from Docker Hub, credentials for accessing the repository are saved in environment variables: `DOCKER_REGISTRY_SERVER_URL`, `DOCKER_REGISTRY_SERVER_USERNAME`, and `DOCKER_REGISTRY_SERVER_PASSWORD`. Because of security risks, none of these reserved variable names are exposed to the application.
::: zone pivot="container-windows"
For IIS or .NET Framework (4.0 or later) based containers, credentials are injected into `System.ConfigurationManager` as .NET app settings and connection strings automatically by App Service. For all other language or framework, they're provided as environment variables for the process, with one of the following prefixes:
- `APPSETTING_`
- `SQLCONTR_`
- `MYSQLCONTR_`
- `SQLAZURECOSTR_`
- `POSTGRESQLCONTR_`
- `CUSTOMCONNSTR_`
::: zone-end
::: zone pivot="container-linux"
This method works both for single-container apps or multi-container apps, where the environment variables are specified in the *docker-compose.yml* file.
::: zone-end
## Use persistent shared storage
::: zone pivot="container-windows"
You can use the *C:\home* directory in your custom container file system to persist files across restarts and share them across instances. The *C:\home* directory is provided to enable your custom container to access persistent storage.
When persistent storage is disabled, writes to the *C:\home* directory aren't persisted across app restarts or across multiple instances. When persistent storage is enabled, all writes to the *C:\home* directory persist. All instances of a scaled-out app can access them. Any existing files already present on the persistent storage when the container starts overwrite any contents in the *C:\home* directory of the container.
The only exception is the *C:\home\LogFiles* directory. This directory stores the container and application logs. This folder always persists upon app restarts if [application logging is enabled](troubleshoot-diagnostic-logs.md?#enable-application-logging-windows) with the **File System** option, whether or not persistent storage is enabled. In other words, enabling or disabling the persistent storage doesn't affect the application logging behavior.
By default, persistent storage is *enabled* on Windows custom containers. To disable it, set the `WEBSITES_ENABLE_APP_SERVICE_STORAGE` app setting value to `false` by using the [Cloud Shell](https://shell.azure.com). In Bash: