Deployment to Azure App Service

The Linux image of App Service has no fonts for Chinese, Japanese and Korean, and a code deployment cannot install any, so reference the fonts package for Linux. A Linux application can be built and published from Windows: the native package carries every library the engine needs, and SelectPdf restores the engine's execute permission, which a zip deployment loses.

The steps use the Azure CLI; the Azure portal offers the same choices (Create a resource > Web App). An App Service plan is created for Windows or for Linux and cannot be changed later.

1. Create a resource group and a plan. Premium v3 gives the fastest conversions (see Performance below); add --is-linux for a Linux plan:

az login
az group create --name selectpdf-rg --location westeurope
az appservice plan create --resource-group selectpdf-rg \
    --name selectpdf-plan --sku P1v3 --is-linux

2. Create the web app with the .NET 10 runtime - DOTNETCORE:10.0 on Linux, dotnet:10 on Windows:

az webapp create --resource-group selectpdf-rg --plan selectpdf-plan \
    --name selectpdf-web --runtime "DOTNETCORE:10.0"

3. Apply two settings.Always On keeps the application loaded while idle, so the Chromium engine stays warm and a request never meets a starting worker. On Windows, also use a 64-bit worker process: a new Windows web app starts as 32-bit.

az webapp config set --resource-group selectpdf-rg --name selectpdf-web \
    --always-on true --use-32bit-worker-process false

4. Publish and deploy the application as a zip file:

dotnet publish -c Release -o publish
cd publish && zip -r ../app.zip . && cd ..
az webapp deploy --resource-group selectpdf-rg --name selectpdf-web \
    --src-path app.zip --type zip

On Windows, create the zip with Compress-Archive publish\* app.zip. From Visual Studio, use Publish > Azure > Azure App Service (Windows or Linux) instead.

5. Open the application at https://selectpdf-web.azurewebsites.net.

Important

With the WEBSITE_RUN_FROM_PACKAGE setting, App Service mounts the deployment zip as wwwroot instead of extracting it, and the engine cannot be started from that mount. Every conversion then fails with "Chromium engine process failed (exit code -1073741515) and no output JSON was produced" - the Windows status STATUS_DLL_NOT_FOUND: the engine's libraries are in the package, but cannot be loaded from it. Remove the setting and deploy normally; zip deploy and Web Deploy extract the application into a writable wwwroot. In Visual Studio, leave Run from package file unselected in the publish profile.

If Run From Package has to stay, copy the engine folder (Chromium-CEF-154.0.28) to a writable folder such as %HOME%\site\engine when the application starts, and set ChromiumEnginePath to the copy. App Service for Linux ignores the setting for a code application, so Linux is not affected.

HTML conversion runs a complete browser and is processor bound, so the plan decides the speed:

Measured in September and October 2026 in West Europe. An S1 instance has one comparatively slow virtual core; choose Premium v3 when conversion time matters, and Basic or Standard for occasional or background conversions.

On Windows, every conversion pays a fixed graphics start-up cost unless WebGlEnabled is False, which is the default. Leave it off unless your pages draw with WebGL.

A 32-bit worker process can use the win-x64 package: the engine then runs in a process of its own (slower, about 3.7 seconds for selectpdf.com on P1v3). With the win-x86 package a 32-bit worker keeps the engine loaded. A 64-bit worker with win-x64 is the recommended combination.

Deploy the web sample of the official samples (windows/Web or linux/Web) to try it: it converts pages, HTML and files with every option of the library.

Other Resources