IronPDF on Azure App Service Linux: Unexpected Chrome Renderer Fails on Cold Start or Underlying Service Updates

Overview

Azure App Service Linux periodically updates its underlying Oryx/Ubuntu base image, which can remove shared libraries that IronPDF's Chrome renderer depends on. On the next cold start, IronPDF must reinstall those dependencies — a process that can take up to 5 minutes. If the application has a short startup timeout, the reinstallation is interrupted, the site fails to start, and the error libnss3.so: cannot open shared object file: No such file or directory is thrown. The fix is to keep LinuxAndDockerDependenciesAutoConfig = true and increase the service timeout to accommodate reinstallation.

Environment

OS: Azure App Service Linux (Ubuntu-based Oryx image)
Affected Versions: IronPDF 2026.4.1
Unaffected Versions: IronPDF 2026.5.2
Hosting: Azure App Service, P0v3 plan, Norway East region
Language/Runtime: .NET 10

Root Cause

This is not an IronPDF version bug. Azure App Service Linux periodically updates its underlying Oryx/Ubuntu base image, which can remove or replace shared libraries like libnss3.so that Chrome depends on. When this happens — whether during a cold start after idle or after an underlying service update — IronPDF must reinstall its native Chrome dependencies from scratch. If the application has a short request timeout configured, the installation is interrupted before it can complete, causing the deployment exception and taking the site down.

Solution

Recommended: Set LinuxAndDockerDependenciesAutoConfig = true and ensure your application timeout is long enough to allow dependency installation to complete (it can take up to 5 minutes on a cold start).Apply the following initialization settings:
```
Logger.LoggingMode = Logger.LoggingModes.All; 
Installation.LinuxAndDockerDependenciesAutoConfig = true; 
Installation.ChromeGpuMode = IronPdf.Engines.Chrome.ChromeGpuModes.Disabled; 
Installation.Initialize(); 
```
Increase your service timeout. If your Azure App Service or application startup has a timeout configured, raise it to at least 10 minutes to account for worst-case dependency reinstallation on cold start. Azure App Service has its own startup timeout settings — verify these are not cutting off the initialization process.