HTML to PDF in Google Cloud · .NET

Convert HTML to PDF in Google Cloud Run and GKE

Q: Do I need to install anything when the service starts?

Nothing. The four system packages are installed in the image when you build it and the runtime files get their execute permission there.

Q: Does the converter run in Google Kubernetes Engine?

The image runs in any Kubernetes cluster. In GKE the image comes from Artifact Registry, which the node pool's service account reads with the Artifact Registry Reader role. One n2-standard-4 node converted 12 two-page documents per second in our test.

Q: How is it licensed in Google Cloud?

A service that runs on several instances needs a Company License; a single instance is covered by a Deployment License.

EvoPdf Next renders HTML to PDF inside your Cloud Run service. The container image carries the rendering runtime and four system packages, so every instance Cloud Run starts converts from its first request, in the first and in the second generation execution environment. The same image runs in Google Kubernetes Engine.

Download EvoPdf Next DemoDownload demo app Try the online demoOnline demo

Version 14.86.0, free to evaluate without registration; the output carries a demo stamp until you set a license key. Perpetual licenses start at 450 USD, or 1200 USD with redistribution and unlimited servers; every license covers any number of developers.

Cloud Run guide · Kubernetes guide · Samples and demos on GitHub · AI agent skills

ConsoleCLI

dotnet add package EvoPdf.Next.HtmlToPdf.Linux

Cloud Run runs x86_64 images; reference EvoPdf.Next.Linux for all the components, with the same code as on any other platform

Cloud Shellgcloud

gcloud run deploy pdf-app \
  --image europe-west3-docker.pkg.dev/PROJECT_ID/pdf-images/pdf-app:1 \
  --region europe-west3 --allow-unauthenticated \
  --memory 2Gi --cpu 2 --timeout 300 \
  --execution-environment gen2

One command from image to public HTTPS service. Step-by-step guide →

Cloud Run, second generation
Cloud Run, first generation
Google Kubernetes Engine
Artifact Registry images
.NET 10 and .NET 8

Execution environments

Both Cloud Run generations convert

The rendering engine is a Chromium build integrated with the library. It works inside the sandbox of the first generation execution environment and in the full Linux environment of the second generation. Choose the generation for the rest of your service; for HTML to PDF the second one is faster.

Second generation

Deploy with --execution-environment gen2. In the Europe (Frankfurt) region an instance with 2 vCPUs and 2 GiB of memory converted a two-page HTML document 4.3 times per second with four conversions in parallel.

The option we recommend for conversions
Same image, same code, same deploy command

First generation

Services that already run in the first generation keep it. With the same instance size and the same document the converter produced 3.2 PDF files per second with four conversions in parallel.

Runs in the gVisor sandbox
No change in the Dockerfile

EvoPdf Next HTML to PDF →

Google Cloud Run

Build, push and deploy a Cloud Run service

The image starts from the Microsoft ASP.NET Core runtime image, installs the four packages the HTML to PDF component needs and listens on port 8080, where Cloud Run sends the requests by default. Push it to a Docker repository in Artifact Registry in the region of the service and deploy it from Cloud Shell.

DockerfileASP.NET Core 10

FROM mcr.microsoft.com/dotnet/aspnet:10.0

# packages for the HTML to PDF component
RUN apt-get update && apt-get install -y libnss3 \
    libatk-bridge2.0-0 libcairo2 libpango-1.0-0 && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY publish/ .
RUN chmod +x evopdf_runtimes/linux-x64/native/evopdf_loadhtml \
    evopdf_runtimes/linux-x64/native/evopdf_pdfprocessor

# the default port of Cloud Run
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]

For .NET 8 start from aspnet:8.0; the packages are the same. Cloud Run guide →

Publish, push, deploy

dotnet publish -c Release -r linux-x64 --self-contained false -o publish
docker build --platform linux/amd64 -t pdf-app .

In Cloud Shell enable Cloud Run and Artifact Registry and create the repository:

gcloud services enable run.googleapis.com artifactregistry.googleapis.com
gcloud artifacts repositories create pdf-images \
  --repository-format=docker --location=europe-west3

Push the image with docker push, signed in with gcloud auth configure-docker europe-west3-docker.pkg.dev or with an access token from Cloud Shell, then run the deploy command shown above.

2 vCPUs and 2 GiB per instance as a starting point, more memory for large documents
A request timeout of 300 seconds leaves room for long pages
For conversions in background tasks after the response, deploy with --no-cpu-throttling

Google Kubernetes Engine

The same image in a GKE cluster

A Deployment runs the image and a Service of type LoadBalancer gives it a public address. The manifest in the Kubernetes guide uses only standard resources; in GKE the image address points to Artifact Registry and the node pool's service account gets the Artifact Registry Reader role. On a single n2-standard-4 node the demo benchmark converted its two-page document at 12 conversions per second with four in parallel, with a median of 324 ms per conversion.

pdf-app.yaml (excerpt)Kubernetes

containers:
- name: pdf-app
  image: europe-west3-docker.pkg.dev/PROJECT_ID/pdf-images/pdf-app:1
  ports:
  - containerPort: 8080
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      memory: 4Gi

Deployment, Service and kubectl commands in the Kubernetes guide →

Sizing the nodes

Nodes with at least 4 vCPUs for production: an n2-standard-4 node gave 12 conversions per second, an e2-standard-2 node 2.9 with two in parallel
More replicas with kubectl scale as the load grows
A new pod converts from its first request, with nothing to install at startup
The Service's targetPort is the port from ASPNETCORE_URLS in the Dockerfile

Dockerfiles for Linux and Windows Kubernetes guide

FAQ

HTML to PDF in Google Cloud: common questions

Which resources does a Cloud Run instance need?

Start with 2 vCPUs and 2 GiB of memory per instance and raise the memory for large documents or many parallel conversions. Cloud Run adds instances as the requests grow and each new instance converts from its first request.

First or second generation execution environment?

Both run the converter with the same image. In our tests the second generation was faster: 4.3 two-page conversions per second against 3.2, with 2 vCPUs, 2 GiB and four conversions in parallel.

Can a service convert after it sends the response?

By default Cloud Run gives processor time to an instance only while it handles requests, which suits conversions made inside a request. For background tasks that convert after the response, deploy with --no-cpu-throttling.

Do I need to install anything when the service starts?

Nothing. The four system packages (NSS, AT-SPI2/ATK bridge, Cairo, Pango) are installed in the image when you build it and the runtime files get their execute permission there.

Does the converter run in Google Kubernetes Engine?

The image runs in any Kubernetes cluster. The Kubernetes guide has the Deployment, the Service and the GKE commands; in GKE the image comes from Artifact Registry, which the node pool's service account reads with the Artifact Registry Reader role. One n2-standard-4 node converted 12 two-page documents per second in our test.

How is it licensed in Google Cloud?

A service that runs on several instances, as Cloud Run and GKE do when they scale, 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 for Linux and build as the image you deploy to Cloud Run or GKE; the library comes from NuGet.

Download EvoPdf Next Demo v14.86.0 Pricing & licensing