---
title: "Document Engine reference architecture | Nutrient"
canonical_url: "https://www.nutrient.io/guides/document-engine/self-hosted/reference-architecture/"
md_url: "https://www.nutrient.io/guides/document-engine/self-hosted/reference-architecture.md"
last_updated: "2026-05-30T02:20:01.237Z"
description: "Document Engine architecture | Nutrient API documentation for Nutrient Document Engine SDK with methods, properties, and code examples."
---

# Document Engine reference architecture

A broad range of platforms is available to you if you choose to host Document Engine yourself, including public cloud vendors or your own data center. Nutrient doesn’t impose any specific requirements on the infrastructure beyond necessary capabilities — e.g. a PostgreSQL database if you’re using Document Engine with [storage](https://www.nutrient.io/guides/document-engine/configuration/asset-storage.md) — and you can use any approach that fits your needs.

Our experience hosting Document Engine at Nutrient, together with insights from customer deployments, has led to a reference architecture that underpins our [managed solutions](https://www.nutrient.io/guides/document-engine/as-a-service.md). This same architecture is the focus of our [guides](https://www.nutrient.io/guides/document-engine/deployment/kubernetes.md), and our Support team has deep expertise with it — we recommend using it as the foundation for your own infrastructure design.

## Opinionated by design

Rather than trying to cover every possible scenario, we focus on an approach that is practical, broadly applicable, avoids vendor lock-in, and keeps prerequisites to a minimum — while still allowing maximum flexibility.

This philosophy naturally led us to [Kubernetes](https://kubernetes.io/) as the platform for orchestrating containers, both for Document Engine and, optionally, its dependencies. To simplify deployment and management, we provide a [Helm chart](https://github.com/PSPDFKit/helm-charts/tree/master/charts/document-engine).

## Reference architecture

To run Document Engine in its most complete configuration, you need:

- A Kubernetes cluster
  - Capable of running Linux containers for ARM64 or AMD64 architectures.
  - With an [Ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress/) to expose Document Engine internally or externally.

- A PostgreSQL database to store metadata and configuration (deployed in the same cluster or externally, with a broad range of managed databases supported).

- An object storage service to store [assets](https://www.nutrient.io/guides/document-engine/configuration/asset-storage.md). Document Engine supports AWS Simple Storage Service (S3) and S3-compatible solutions (such as Google Cloud Storage), as well as Azure Blob Storage.

- A [cache](https://www.nutrient.io/guides/document-engine/configuration/cache.md) service to speed up rendering and processing of frequently accessed documents. Document Engine supports Redis.

The rest is handled by Helm. [Document Engine Helm chart values](https://github.com/PSPDFKit/helm-charts/blob/master/charts/document-engine/values.yaml) contain all the necessary details to connect the building blocks. Helm can also be managed by GitOps tools like [ArgoCD](https://argoproj.github.io/cd/) or [Flux](https://fluxcd.io/flux/concepts/), or other infrastructure-as-code solutions of your choice.

Refer to our guides for additional information on [setting up Document Engine using Helm](https://www.nutrient.io/guides/document-engine/deployment/helm.md) and [setting up Ingress](https://www.nutrient.io/guides/document-engine/deployment/ingress.md) to expose it to your applications.

We also have [public examples](https://github.com/PSPDFKit/document-engine-reference-architecture/tree/master/examples) for setting up a Kubernetes cluster and installing Document Engine.