Security & deployment

Your documents never leave your servers

Doconut is a .NET library you host yourself, not a document service you upload to. Files are opened, rendered and served entirely inside your own infrastructure — which is what makes it viable for regulated workloads where the document itself can never cross an organizational boundary.

0
documents sent to Doconut
100%
rendering on your own servers
Offline
licensing with a local .lic file

Your infrastructure — trust boundary

  1. 1

    Your application

    Reads the file from wherever it already lives: local disk, a network share, S3, Azure Blob, a database column.

  2. 2

    Doconut middleware

    Registered in your own pipeline with AddDoconut() and UseDoconut(). Runs in your process, under your identity, in your network.

  3. 3

    Page images

    Viewer.OpenDocumentAsync() renders paginated page images and returns an opaque session token. The source file is never handed to the browser.

  4. 4

    The browser

    The JavaScript widget requests pages by session token from your own endpoint. It never sees a file path, a storage URL, or the original bytes.

Never contacted while rendering

  • Doconut servers
  • Any third-party conversion API
  • Any cloud OCR or AI service
  • Any external font or asset CDN

Architecture

Where a document actually goes

A hosted viewer service works by receiving your file. Doconut works by never receiving it. The document is read by your own process, rasterized into page images by your own process, and streamed to the browser by your own process — Doconut is the library doing the work, not a party to the transfer.

Security model

What the design actually guarantees

On-premise by construction

There is no SaaS mode and no hosted fallback. Doconut ships as DLLs you reference; if your servers are offline, rendering still works. The absence of an upload path is a property of the architecture, not a configuration setting somebody can flip.

Opaque session tokens

OpenDocumentAsync() returns an opaque string, not a file path or an identifier the client can tamper with. The browser cannot enumerate documents, guess a neighbouring token, or rewrite a token into a different file. Treat tokens as secrets: never log them and never persist them client-side beyond the viewer.

Authorization stays yours

Doconut never decides who may read a document. You call OpenDocumentAsync() only after your own authorization check has passed, so the viewer inherits whatever access control your application already enforces — roles, tenancy, record-level permissions, all of it.

No document leaves as a file

The browser receives rendered page images, not the source document. A user who can view a contract cannot trivially exfiltrate the original DOCX, and a leaked page image does not carry the tracked changes, comments, hidden columns or metadata the source file did.

Password-protected documents

Encrypted and password-protected files are opened server-side with the password supplied by your code. The password crosses process boundaries only inside your own application — never to the client, never to us.

Offline licensing

Licensing is a local .lic file resolved through options.LicensePath or Viewer.DoconutLicense(path). There is no activation callback and no runtime licence check over the network, which is what makes air-gapped deployment possible at all.

Compliance

How Doconut fits a regulated environment

An honest framing matters more here than a wall of logos. Doconut is a library, not a service provider. We never receive, store or process your documents, which means we do not become a processor, a sub-processor or a business associate when you deploy it. That removes an entire category of paperwork — but the controls around the deployment remain yours to operate and evidence.

HIPAA

Because protected health information never reaches Doconut, there is no business associate relationship to paper over with a BAA. Records and DICOM studies are rendered inside your own environment. The safeguards themselves — access control, audit logging, encryption at rest and in transit — remain your responsibility, exercised in the application you already run.

GDPR and data residency

Personal data stays wherever you put it. There is no cross-border transfer introduced by the viewer, because there is no transfer at all: the document is read and rendered in the same jurisdiction as the server you deployed to. Residency becomes a hosting decision, not a vendor negotiation.

Government and defence

Deployments with no outbound internet access are a supported configuration rather than a workaround. Package the DLLs and the .lic file, install into the enclave, and the viewer runs indefinitely for the version range the licence covers.

What we do not claim

Doconut does not advertise SOC 2, ISO 27001 or HITRUST certification, and you should not represent it as certified. The security argument is architectural: the vendor is never in the data path. If your auditor needs a control narrative, that is the narrative.

Deployment

Where it can run

Windows Server

The classic target. IIS or Kestrel, in your own data centre or on a cloud VM you control.

Docker

Supported for .NET 8. Ship the viewer as part of your own image and keep licence files out of the layer with a mounted secret.

Web farm and distributed

Multiple nodes behind a load balancer share the render cache, so a session opened on one node stays readable on another.

Air-gapped enclave

No outbound connectivity required at any point after installation — not for rendering, not for conversion, not for licensing.

Operations

Hardening checklist

None of these are exotic. They are the handful of things that most often go wrong in a real deployment, in the order they usually bite.

  1. 1Authorize before you open. Call OpenDocumentAsync() only after your own permission check has run — the viewer will happily render anything you hand it.
  2. 2Keep the .lic file out of source control and out of your container image. Store it in a directory with restricted read access and mount it as a secret.
  3. 3Never log session tokens. They belong in memory and in the viewer config, not in request logs, APM traces or error reports.
  4. 4Scope the resource endpoint. UseDoconutResources() serves viewer assets — put it behind the same authentication as the rest of the application, not in an anonymous branch of the pipeline.
  5. 5Give the render cache a real lifetime. Cached page images are derived copies of sensitive documents; evict them on a schedule that matches your retention policy.
  6. 6Pin your DLL versions and archive them alongside the licence. A licence is tied to a version range; keeping both together is what guarantees the deployment still starts in five years.

Security questions we actually get asked

Are documents ever uploaded to Doconut?

No. Doconut is a library that runs inside your application. There is no upload endpoint, no hosted rendering tier and no telemetry channel that carries document content. If your server has no route to the internet, the viewer still renders normally.

Can a user download the original file from the viewer?

Not through the viewer. The browser receives rendered page images addressed by an opaque session token. If you want a download button, you implement it yourself — which means the decision to release the source file stays an explicit choice in your own code.

What exactly is a session token?

An opaque string returned by Viewer.OpenDocumentAsync() that the JavaScript widget presents to fetch pages. It is not a document identifier, not a path, and not something to store or reuse. Treat it like a bearer credential with a short life.

Does the licence phone home?

No. Licensing resolves a local .lic file. There is no activation call and no periodic revalidation, which is precisely why air-gapped installations work.

Can it run with no internet access at all?

Yes. Rendering, conversion and licensing are all local. The only thing an internet connection buys you is downloading updates, which you can equally carry in on media.

Is Doconut SOC 2 or ISO 27001 certified?

We do not claim either, and you should not represent the product as certified. The relevant fact for an audit is different and usually stronger: Doconut is never in the data path, so there is no vendor environment for an auditor to assess in the first place.

How are password-protected documents handled?

Your code supplies the password when opening the document, server-side. It is used to decrypt in your own process and is never transmitted to the browser or anywhere else.

Evaluate it inside your own network

Request a temporary licence and run Doconut on your own infrastructure, against your own documents, with your own firewall rules in place. That is the only evaluation that proves the point.

100% rendering on your own servers