Compare deployment options and use cases for Nutrient document solutions

When functioning independently, Document Engine acts as a backend document processing and management service, enabling the programmatic manipulation of documents without the need for a user interface.

It supports two operational modes:

• Without storage — Stateless headless processing, where inputs are provided per request, and results are processed without persistent storage.

• With storage — Includes PostgreSQL for metadata and S3 for binary assets, enabling integration with frontend clients and broader access via licensed APIs.

These modes align with distinct licensing configurations:

• Server components — For backend APIs, available in both modes.

• Client components — For frontend UI/API integrations, only available in “with storage” mode. Document Engine is flexible for integration in custom apps or workflows, regardless of the platform, and is delivered as a Linux container.

Use cases

Consider a use case where a customer only requires backend document processing capabilities, such as OCR, format conversion, or bulk redaction. There’s either no user interface, or it doesn’t require exposing document editing functions that would require the Web SDK.

Examples

• A medical clinic that needs to convert every patient scan into a PDF format.

• A government agency that requires the redaction of personal information from documents before archiving.

• A web store that requires adding additional information to all invoices coming from a payment system integration.

These use cases don’t necessitate complex interactive document operations in the user interface, or they just consist of straightforward, automated backend document processing.

Deployment

1. Self-hosted: For organizations with in-house infrastructure design and operations capabilities.

• We provide a recommended setup example (as if we were setting this up ourselves) for clients to follow in their infrastructure.

• Private, self-hosted infrastructure. Clients have full control over the infrastructure to meet compliance requirements.

• Highly scalable. Suitable for processing documents in batches.

• For all business sizes.

2. Managed (Nutrient): For those seeking infrastructure simplicity; Nutrient handles deploying and operating in the cloud.

• Managed Document Engine eliminates the need for clients to set up and manage their own infrastructure.

• Service offered to manage infrastructure using various public cloud providers.

• Clients maintain ownership of their cloud instance license in public clouds, ensuring exclusive use.

3. Web SDK + Document Engine: For organizations seeking the flexibility of switching between client-side and server-side support.

• Hosted on our infrastructure or their infrastructure.

• Client-side user interface.

• Significantly reduced client-side processing load. When integrated with Nutrient Web SDK, it enables client applications to offload heavier operations that come from PDF viewing and editing.

• Run Document Engine from the backend of the client’s application to automate processes, or as a backend for the Web SDK.

• Real-time collaboration on documents for Web and mobile SDKs.

4. Document Web Services (DWS) API: For software builders in need of headless document processing with minimal operational overhead.

Capability comparison

Component comparison

When integrated with Nutrient Web SDK, Document Engine facilitates backend-powered PDF viewing and editing for client-side applications. This includes a full-featured document editing UI, PDF streaming for incremental viewing, and support for hybrid mode, where processing alternates between client-side (browser) and server-side (Document Engine).

Hybrid mode currently supports features such as the Content Editor component, which loads documents from Document Engine, processes them client-side in the Web SDK, and then updates the document back in the server. This mode requires Document Engine with storage, utilizing client components licensed for specific features (e.g. annotations).

Licensing can mix and match client and server components, allowing for flexibility in feature access. In this case, Document Engine is deployed similar to headless Document Engine, but with a different license to enable client-side integrations.

Use cases

Ideal for scenarios requiring a client-side interface to interact with documents, along with any of the following:

• More lightweight end user application through offloading the operations from the browser to the backend.

• Superior performance in document rendering, lightening the load on end user machines, especially when dealing with large-sized PDF documents (50+ pages, containing numerous images, etc.).

• For performance reasons, required if documents are larger than 200 MB in size, but should be considered for documents larger than 50 MB.

• Real-time collaboration on documents or any other workflow that requires multiple users working on the same document, in real time or not.

• A blend of UI and document processing, as outlined for headless Document Engine.

• Requirement not to store documents locally or in the browser (document is stored on the server).

Examples

• A government agency aims to provide its employees with the capability to view and work with documents and reports exceeding 300 pages. It focuses on eliminating slow opening times and sluggish rendering of these large documents in the browser.

• A medical clinic that requires the ability to annotate image-heavy patient scans directly within its proprietary app. After completing the annotations, these scans need to be converted into PDFs without the need to switch applications.

• An educational institution, which distributes digital documents (including some large, image-heavy PDFs) among staff and students lacking powerful laptops, aims to expedite its operations. Additionally, it seeks to streamline certain document-related processes, such as automatically prepopulating teachers’ and students’ names on tests and reports.

Deployment

1. Self-hosted: For organizations with in-house infrastructure design and operations capabilities.

• We provide a recommended setup example (as if we were setting this up ourselves) for clients to follow in their infrastructure.

• Private, self-hosted infrastructure. Clients have full control over the infrastructure to meet compliance requirements.

• Highly scalable. Suitable for processing documents in batches.

• For all business sizes.

2. Managed (Nutrient): For those seeking infrastructure simplicity; Nutrient handles deploying and operating in the cloud.

• Managed Document Engine eliminates the need for clients to set up and manage their own infrastructure.

• Service offered to manage infrastructure using various public cloud providers.

• Clients maintain ownership of their cloud instance license in public clouds, ensuring exclusive use.

3. Web SDK + Document Engine: For organizations seeking the flexibility of switching between client-side and server-side support.

• Hosted on our infrastructure or their infrastructure.

• Client-side user interface.

• Significantly reduced client-side processing load. When integrated with Nutrient Web SDK, it allows client applications to offload heavier operations that come from PDF viewing and editing.

• Run Document Engine from the backend of the client’s application to automate processes or as a backend for the Web SDK.

• Real-time collaboration on documents for Web and mobile SDKs.

4. Document Web Services (DWS) API: For software builders in need of headless document processing with minimal operational overhead.

Capability comparison

Component comparison

Formerly known as Web Standalone, the Web SDK is designed for 100 percent client-side document viewing and editing, with all processing performed entirely in the browser. It operates independently, without requiring a backend server or integration with Document Engine.

The Web SDK is ideal for lightweight document workflows that don’t demand backend processing or real-time collaboration. Typical use cases include viewing, annotating, and editing small-to-medium-sized documents directly in the browser, making it a cost-effective solution for environments with limited infrastructure or simpler document processing needs.

Use cases

Ideal for straightforward workflows that don’t demand rapid document opening and rendering (suitable for documents of ordinary size), that lack the need for backend bulk processing and real-time collaboration, and where there’s limited expertise and budget for managing server infrastructure.

Examples

• A small sales office seeking to enable its sales representatives to work on few-page PDF invoices, allowing them to edit form fields and send them for signatures.

• A medical office aiming to implement online patient intake forms, making them accessible for patients to fill out directly from their browsers.

Deployment

100 percent frontend: Can be added with npm install, and it then loads, renders, and saves PDFs — all in the browser using WebAssembly.

Capability comparison

Component comparison