Convert HTML to PDF in Azure App Service, Azure Functions and containers
EvoPdf Next renders HTML to PDF inside your Azure application. Windows or Linux App Service, Azure Functions, Container Apps and AKS, with nothing to install and no server to run. Applications built on the Classic library can convert through an EVO PDF Server hosted on an Azure Virtual Machine or Cloud Service, using the .NET client.
Version 14.86.0. Building EVO PDF libraries since 2010. Evaluate without registration; the demo output is watermarked until you set a license key. Perpetual licenses from 450 USD, or 1200 with redistribution and unlimited servers. Every license covers any number of developers.
Azure guides in the docs · Samples and demos on GitHub · AI agent skills
dotnet add package EvoPdf.Next.HtmlToPdf.Windows
App Service on Windows; for App Service on Linux and Linux containers reference EvoPdf.Next.HtmlToPdf.Linux; the code is identical
using EvoPdf.Next; // runs inside the App Service worker, no server needed var converter = new HtmlToPdfConverter(); byte[] pdf = converter.ConvertUrl(url); return File(pdf, "application/pdf", "page.pdf");
- Azure App Service, Windows and Linux
- Azure Functions, Windows and Linux
- App Service and Functions from a container image
- Container Apps, AKS, any Docker host
- Virtual Machines and Cloud Services
- .NET 6–10 and .NET Framework 4.6.2+
The same package on both App Service flavours
The rendering engine is a Chromium build integrated with the library, light enough for the App Service sandbox on either platform. Reference the package for your platform, publish and convert: Windows or Linux, App Service or Functions. HTML to PDF is the component that asks for CPU and memory, so B1 is the smallest plan on Windows, B2 is the one to develop on and a Premium plan such as P1v3 is the one for production.
Windows App Service
Reference EvoPdf.Next.Windows, publish, convert. The 64-bit worker needs no configuration, no startup command and nothing installed on the instance.
- B1 for low volume, B2 for development, P1v3 or higher in production
- Free and Shared plans are not suitable for the converter
Linux App Service
The same code and the same API with EvoPdf.Next.Linux. The HTML to PDF component needs four system libraries; App Service does not keep installed packages after a restart, so they are installed on every start, from the Startup Command in the Azure Portal or from your own code. Deployed as a container image, the application has them already and installs nothing. The other components need nothing extra.
- F1 is the minimum supported tier, B2 for development, P1v3 or higher in production
Publish and run on App Service
Windows App Service needs no configuration beyond the NuGet package. On Linux App Service the four system libraries of the HTML to PDF component are installed at every start, because the platform does not persist installed packages after a restart, or they come with the container image of the application.
Windows
Reference EvoPdf.Next.Windows (or a single component such as EvoPdf.Next.HtmlToPdf.Windows), publish, done. Plans: B1 for low volume, B2 for development, P1v3 or higher for production; the Free and Shared tiers are not suitable for conversions.
Linux
Reference EvoPdf.Next.Linux and publish. Then, in the Azure Portal, open your App Service, go to Settings › Configuration › Stack settings and put the package installation in front of the existing Startup Command, on the same line. Save, then restart the app from the Overview page; the first start takes a few minutes while the packages install.
# one line, before the dotnet command
apt update && apt install -y libnss3 libatk-bridge2.0-0 libcairo2 libpango-1.0-0 && dotnet MyApp.dll
Alternative in code, before the first conversion: Installation.ConfigureRuntime(false, null, "apt update && apt install -y libnss3 libatk-bridge2.0-0 libcairo2 libpango-1.0-0");
For production, deploy a container image instead: App Service for Containers runs the image with the packages in it, with no Startup Command and nothing to install when the app starts. Create the web app with az webapp create --container-image-name myregistry.azurecr.io/pdf-app:1 and set WEBSITES_PORT=8080.
HTML to PDF in an Azure Function
Pick the App Service or Premium plan type; the Consumption and Flex Consumption plans are not suitable for the converter. On Windows nothing else is needed. On Linux the setup follows the way the function app is deployed. Created and published from Visual Studio, it runs from its package with a read-only application folder, so the library copies the runtime to a writable location and installs the system packages itself. A zip archive deployed with the Azure CLI runs the runtime in place and a container image needs no setup at all. Use B2 or higher.
// once, before the first conversion; later calls are ignored Installation.ConfigureRuntime(true, null, "apt update && apt install -y libnss3 libatk-bridge2.0-0 libcairo2 libpango-1.0-0"); // PDF to text, search, images (PDF Processor component) PdfProcessorInstallation.ConfigureRuntime(true, null);
FROM mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated10.0
RUN apt-get update && apt-get install -y libnss3 \
libatk-bridge2.0-0 libcairo2 libpango-1.0-0
ENV AzureWebJobsScriptRoot=/home/site/wwwroot
COPY publish/ /home/site/wwwroot
RUN chmod +x /home/site/wwwroot/evopdf_runtimes/linux-x64/native/evopdf_loadhtml \
/home/site/wwwroot/evopdf_runtimes/linux-x64/native/evopdf_pdfprocessor
# Cloud Shell, on an App Service or Premium plan
az functionapp create --name pdf-func \
--resource-group pdf-app-rg --plan pdf-plan \
--storage-account mystorage --functions-version 4 \
--image myregistry.azurecr.io/pdf-func:1ConfigureRuntime call, nothing installed at startup. Container image steps →HTML to PDF in Azure Container Apps
Container Apps runs the Linux image of your application with its own HTTPS address and adds replicas when the requests grow. The image carries the runtime and the four system packages, so a new replica converts from its first request. Push the image to Azure Container Registry and create the application from Cloud Shell; the same image runs in App Service for Containers and in AKS.
az containerapp create --name pdf-app \
--resource-group pdf-app-rg --environment pdf-env \
--image myregistry.azurecr.io/pdf-app:1 \
--registry-server myregistry.azurecr.io \
--registry-username myregistry \
--registry-password "" \
--ingress external --target-port 8080 \
--cpu 2 --memory 4Gi \
--min-replicas 1 --max-replicas 3Sizing and scaling
- 2 vCPUs and 4 GiB per replica
- One replica kept running, so no request waits for the application to start
- Measured in West Europe with 2 vCPUs and 4 GiB: 6 two-page conversions per second with four in parallel
HTML to PDF in an AKS cluster
The image of Container Apps runs in AKS from a Deployment and a Service of type LoadBalancer. Create the cluster with --attach-acr and the nodes pull the image from your registry without credentials in the manifest; a new pod converts from its first request.
containers:
- name: pdf-app
image: myregistry.azurecr.io/pdf-app:1
ports:
- containerPort: 8080
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
memory: 4GiNodes and pods
- Nodes with at least 4 vCPUs for production, such as Standard_D4s_v3
- A pod reserves half a vCPU and 1 GiB and uses more CPU when the node has it free
- Measured on a 2 vCPU node: a simple page in about 330 ms, 3 conversions per second with four in parallel
HTML to PDF in Azure: common questions
Which App Service plan does the converter need?
On Windows the smallest supported plan is B1; the Free and Shared tiers are not suitable. On Linux the Free F1 tier is the minimum supported one, enough for testing or low volume. For development we recommend B2 on either platform; for production a Premium plan such as P1v3.
Can I use the Consumption plan for Azure Functions?
No, the Consumption and Flex Consumption plans cannot run the rendering engine. Use an App Service plan or a Premium plan; on Linux the minimum is B2. The target runtime is Portable.
Do I need to install anything on the Azure host?
On Windows, nothing. On Linux App Service and Functions deployed from code, four system packages (NSS, AT-SPI2/ATK bridge, Cairo, Pango) are installed at startup through the Startup Command or Installation.ConfigureRuntime. Container images carry the packages, so App Service, Functions, Container Apps and AKS install nothing when they start them.
Which resources does a Container Apps replica need?
We recommend 2 vCPUs and 4 GiB of memory per replica, the largest size of the Consumption profile. Keep one replica running with --min-replicas 1 so that requests never wait for the application to start; Container Apps adds replicas up to --max-replicas as the requests grow.
Does the converter run in Azure Kubernetes Service?
The Linux image of the application runs in AKS from a Deployment and a LoadBalancer Service. A pod reserves half a vCPU and 1 GiB of memory, with a 4 GiB memory limit; we recommend nodes with 4 vCPUs or more for production.
Does the Classic library run in App Service?
The Classic rendering engine does not run inside App Service; Classic applications convert through an EVO PDF Server on a Virtual Machine or Cloud Service using the .NET client. Moving to EvoPdf Next removes the server: see the migration guide.
How is it licensed in Azure?
An application running on several instances (autoscaling, load balancing, containers) needs a Company License; a single instance is covered by a Deployment License. Pricing & licensing.
Download the demo application
The ASP.NET Core demo with complete C# source, ready to publish to App Service or to build as a container; the library comes from NuGet.