# IronPDF on Azure Linux with WEBSITE_RUN_FROM_PACKAGE
When deploying a .NET API using IronPDF on an Azure Linux App Service with `WEBSITE_RUN_FROM_PACKAGE` enabled, the Chrome renderer fails to deploy and the application throws an error on startup.
```txt
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
```
When `WEBSITE_RUN_FROM_PACKAGE` is set, the `/home/site/wwwroot` directory becomes read-only. IronPDF needs to extract native Chrome renderer binaries and runtime libraries to a writable location at startup, so the read-only restriction blocks deployment. In addition, Azure's default Linux environment may not have the required system libraries pre-installed, which causes the missing shared object errors.
## Solution
Four options are available depending on your deployment constraints.
If you stay on a native package, IronPDF also needs a writable location for its binaries. From IronPDF `2026.8.1`, the deployment error names this cause and the available remedies directly, and you can relocate the writable paths yourself:
```csharp
IronPdf.Installation.TempFolderPath = "/home/data/ironsoftware/";
IronPdf.Installation.CustomDeploymentDirectory = "/home/data/ironsoftware/";
```
Set these before the first IronPDF call. This addresses the read-only filesystem, but not the missing system libraries, which still need one of the options below.
### Option 1: Install Missing Dependencies via SSH
Access the App Service via SSH and run the following commands to install the required system libraries:
```bash
apt update
apt install -y libc6-dev libgtk2.0-0 libnss3 libatk-bridge2.0-0 \
libx11-xcb1 libxcb-dri3-0 libdrm-common libgbm1 libasound2 \
libxkbcommon-x11-0 libxrender1 libfontconfig1 libxshmfence1
```
This is a temporary fix. Packages installed this way do not persist across restarts and are not suitable for production environments that have outbound firewall restrictions. For the full list of required packages by Linux distribution, see the [Linux deployment guide](/get-started/linux/).
### Option 2: Use a Custom Docker Container (Recommended for Linux)
Build a custom Docker image based on Ubuntu or Debian, install the required system packages with `apt`, and include the `IronPdf` and `IronPdf.Native.Chrome.Linux` NuGet packages in your project file. This approach gives the renderer a writable filesystem and pre-installed dependencies at image build time.
Add the matching NuGet packages to your `.csproj`:
```xml
<PackageReference Include="IronPdf" Version="*" />
<PackageReference Include="IronPdf.Native.Chrome.Linux" Version="*" />
```
Make sure the version of `IronPdf.Native.Chrome.Linux` matches your `IronPdf` package version. Including the native package in the project prevents IronPDF from attempting a runtime download, which would fail in a read-only or network-restricted environment.
See the [IronPDF Docker guide](/get-started/ironpdf-docker/) for a full Dockerfile example.
### Option 3: Migrate to a Windows App Service
Windows App Services do not have the same filesystem permission restrictions for `WEBSITE_RUN_FROM_PACKAGE`. IronPDF's Windows runtime libraries are natively supported and can be extracted without issue. Migrating to a Windows App Service removes the root cause entirely.
### Option 4: Use IronPdf.Slim with a Remote IronPdfEngine
Install [IronPdf.Slim](https://www.nuget.org/packages/IronPdf.Slim/) and point it at a remote [IronPdfEngine](/get-started/ironpdfengine/). Rendering runs on the engine, so no Chrome renderer binaries or Linux system libraries have to be deployed into the read-only `/home/site/wwwroot` at all, and `WEBSITE_RUN_FROM_PACKAGE` can stay enabled.
Use IronPDF `2026.8.1` or later for this. On earlier versions, a startup file system scan can fail under `WEBSITE_RUN_FROM_PACKAGE` before the engine connection is used. That failure is covered in [Startup Crash with Run From Package](/troubleshooting/azure-website-run-from-package-startup-crash/).
When deploying a .NET API using IronPDF on an Azure Linux App Service with WEBSITE_RUN_FROM_PACKAGE enabled, the Chrome renderer fails to deploy and the application throws an error on startup.
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
Error while deploying IronPdf Chrome renderer: 'Multiple issues occurred while trying to deploy Chrome (libatk-1.0.so.0: cannot open shared object file: No such file or directory) (IronInterop.so: cannot open shared object file: No such file or directory) (Read-only file system: '/home/site/wwwroot/runtimes')'
Text
When WEBSITE_RUN_FROM_PACKAGE is set, the /home/site/wwwroot directory becomes read-only. IronPDF needs to extract native Chrome renderer binaries and runtime libraries to a writable location at startup, so the read-only restriction blocks deployment. In addition, Azure's default Linux environment may not have the required system libraries pre-installed, which causes the missing shared object errors.
Solution
Four options are available depending on your deployment constraints.
If you stay on a native package, IronPDF also needs a writable location for its binaries. From IronPDF 2026.8.1, the deployment error names this cause and the available remedies directly, and you can relocate the writable paths yourself:
Set these before the first IronPDF call. This addresses the read-only filesystem, but not the missing system libraries, which still need one of the options below.
Option 1: Install Missing Dependencies via SSH
Access the App Service via SSH and run the following commands to install the required system libraries:
This is a temporary fix. Packages installed this way do not persist across restarts and are not suitable for production environments that have outbound firewall restrictions. For the full list of required packages by Linux distribution, see the Linux deployment guide.
Option 2: Use a Custom Docker Container (Recommended for Linux)
Build a custom Docker image based on Ubuntu or Debian, install the required system packages with apt, and include the IronPdf and IronPdf.Native.Chrome.Linux NuGet packages in your project file. This approach gives the renderer a writable filesystem and pre-installed dependencies at image build time.
Make sure the version of IronPdf.Native.Chrome.Linux matches your IronPdf package version. Including the native package in the project prevents IronPDF from attempting a runtime download, which would fail in a read-only or network-restricted environment.
Windows App Services do not have the same filesystem permission restrictions for WEBSITE_RUN_FROM_PACKAGE. IronPDF's Windows runtime libraries are natively supported and can be extracted without issue. Migrating to a Windows App Service removes the root cause entirely.
Option 4: Use IronPdf.Slim with a Remote IronPdfEngine
Install IronPdf.Slim and point it at a remote IronPdfEngine. Rendering runs on the engine, so no Chrome renderer binaries or Linux system libraries have to be deployed into the read-only /home/site/wwwroot at all, and WEBSITE_RUN_FROM_PACKAGE can stay enabled.
Use IronPDF 2026.8.1 or later for this. On earlier versions, a startup file system scan can fail under WEBSITE_RUN_FROM_PACKAGE before the engine connection is used. That failure is covered in Startup Crash with Run From Package.
Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.
