Which document extraction products genuinely run on hardware you control, what the vendor containers actually support once you read the version notes, and the question worth asking before any of it: does your policy really require on premise, or does it require a signed agreement?
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Uploading...
Try it on a non-sensitive document first. Seeing the extraction quality is the fastest way to size what you would be rebuilding in house.
On premise OCR software runs the extraction models on hardware you control rather than sending documents to a vendor's cloud. Three approaches are real today: vendor containers you run under your own Docker or Kubernetes, an open-weight vision model you host on your own GPU, and a traditional licensed capture platform installed on your servers. Of the three hyperscalers, only Microsoft publishes containers for its document extraction service, and those containers still connect out to Azure to report billing. AWS Textract and Google Document AI have no on premise deployment at all.
The important thing to establish before any of this is which obligation you are actually satisfying. A surprising share of on premise projects start because a security questionnaire used the phrase, and finish six months later having rebuilt something a signed data processing agreement would have covered. The rest of this page is written for both readers: the one who genuinely cannot let a document leave the building, and the one who has not yet checked.
These differ far more in what you end up operating than in what they cost. Read the last column first.
| Approach | What you run | What it bills in | What you own |
|---|---|---|---|
| Vendor containers | Docker images from the vendor registry, on your own hardware | Per page, metered through a connected cloud resource | The servers, the orchestration, the upgrade cadence |
| Self hosted open model | An open-weight vision model on your own GPU | GPU hours, billed continuously whether idle or not | Everything: inference server, confidence, validation, review |
| Licensed capture platform | A traditional enterprise capture suite installed on your servers | Annual license, usually volume banded, sales quoted | Servers, the platform, and the professional services to configure it |
| Cloud product with controls | Nothing, the vendor runs it under a signed agreement | Per page, no infrastructure | Nothing operationally, but you own the vendor risk assessment |
The second row is the one people underestimate, and it is costed out in full on the self hosted OCR cost reference: a GPU bills 730 hours a month whether it reads a page or not, so break-even against a $1.50 per 1,000 pages API sits around 391,700 pages a month on the cheapest adequate card. If you are considering the best known open model specifically, its published figures are worked through on the olmOCR pricing page.
Yes, and it is the most complete on premise option of the three hyperscalers. What the marketing does not lead with is which models made it into the current container release.
| Model | Newest container version supporting it | That version went GA | What that means on premise |
|---|---|---|---|
| Read (text and OCR) | v4.0 | 2024-11-30 | Current generation available on premise |
| Layout (tables, structure) | v4.0 | 2024-11-30 | Current generation available on premise |
| Invoice | v3.1 | 2023-07-31 | On premise runs the 2023 model, and requires the Layout container too |
| Receipt | v3.1 | 2023-07-31 | On premise runs the 2023 model, and requires Read or Layout |
| ID Document | v3.1 | 2023-07-31 | On premise runs the 2023 model, and requires the Read container |
| General Document | v3.0 | 2022-08-31 | On premise runs the 2022 model, and requires the Layout container |
| Business Card | v3.0 | 2022-08-31 | On premise runs the 2022 model, and requires the Read container |
| Custom Template | v3.0 | 2022-08-31 | Your own trained models, on the 2022 release, plus Layout |
The v4.0 container release, GA in November 2024, supports Read and Layout only. Invoice, Receipt and ID Document containers are the v3.1 release from July 2023. Custom models and General Document are the v3.0 release from August 2022. So the moment your requirement is structured invoice extraction rather than plain text, running Azure on your own hardware means running a model that is two to three years older than the one the cloud endpoint serves. That is a real accuracy difference and it is not mentioned anywhere near the word container.
Microsoft's own prerequisites state that Docker must be configured to allow the containers to connect with and send billing data to Azure, and a container refuses to start unless the EULA, Billing endpoint and ApiKey values are all supplied. Your documents stay inside the network, which is usually the point, but the deployment is not disconnected and cannot be dropped into a network with no egress. The meter it reports to is the same one the cloud service uses, so the rates on our Azure Document Intelligence pricing breakdown apply to the containers too. If your requirement is genuinely air gapped operation, confirm that arrangement with Microsoft in writing before you plan around it.
Neither of the other two hyperscalers offers an equivalent. AWS publishes no container or on premise install for Textract; the strongest available controls are regional endpoints and VPC endpoints, which govern the network path rather than where processing happens. Google publishes none for Document AI either, offering regional processing, VPC Service Controls and customer-managed encryption keys instead. Those are meaningful controls and they satisfy a lot of policies, but none of them are on premise, and a vendor questionnaire that asks for on premise will not accept them.
Minimums published by Microsoft per container. These are CPU workloads, not GPU, which is the pleasant surprise in the whole exercise. Microsoft recommends 8 cores and 24 GB for every container regardless of the minimum.
| Container | Minimum cores | Minimum memory | Also requires |
|---|---|---|---|
| Read | 8 cores | 10 GB | Nothing |
| Layout | 8 cores | 16 GB | Nothing |
| Invoice | 8 cores | 16 GB | Layout |
| Receipt | 8 cores | 11 GB | Read or Layout |
| ID Document | 8 cores | 8 GB | Read |
| Business Card | 8 cores | 16 GB | Read |
| Custom Template | 8 cores | 16 GB | Layout |
| General Document | 8 cores | 16 GB | Layout |
Note the dependency column, because it changes the sizing conversation. Invoice does not run alone: it requires the Layout container alongside it, so an on premise invoice pipeline is two containers at 8 cores and 24 GB each before you have processed a page. Receipt needs Read or Layout, ID Document needs Read, and Custom Template needs Layout. Plan for pairs, not singles.
An open-weight model is a different shape of problem: no CPU container, but a GPU with at least 12 GB of video memory, which in practice means a 24 GB class card and a monthly bill that starts whether or not any documents arrive. The self hosted OCR cost page has the per-card rates and the volume each one needs to justify itself.
The most common real driver is not a regulation, it is a clause. A client, a prime contractor or a data sharing agreement states that their documents may not be transmitted to a third party. That is not negotiable by architecture, and it is the one case where on premise is simply the requirement.
A policy that documents must remain within a jurisdiction, a facility or a specific network segment. Worth checking carefully: many residency rules are satisfied by a vendor processing in a named region under contract, which is a much cheaper answer than running the models yourself.
Some material simply cannot cross a boundary, whatever agreement is in place. In those environments the question is not which vendor is cheaper but which vendor ships something that runs disconnected, which is a much shorter list than the market implies.
Sites with intermittent or restricted networks still have to process paperwork. This is the case where a container that must phone home to a billing endpoint quietly fails to solve the problem, so check that requirement before you choose the vendor.
Where DocuOCR sits deserves a straight answer rather than a hedge. It is a cloud product. Documents are processed under US data handling with encryption in transit and at rest, role-based access, retention controls and a data processing agreement, which is what most banking, insurance and healthcare policies actually ask for once someone reads them closely. If your requirement is genuinely that nothing leaves your network, we are not the right fit and this page has hopefully saved you a call. If your requirement is a defensible answer to a security questionnaire, start by uploading one non-sensitive document and seeing whether the extraction quality is even worth the architecture conversation.
Upload a non-sensitive document, look at the fields and the confidence scores, and find out whether the accuracy justifies the deployment conversation at all. It takes about a minute.
Self hosted OCR cost
Every GPU, every volume, break-even
olmOCR pricing
What the best-known open model really costs
Azure Document Intelligence alternative
The managed comparison, side by side
Government document processing
FedRAMP, StateRAMP and NIST context
Healthcare document processing
HIPAA aligned handling and BAA framing
OCR API pricing comparison
The buyer view across the market
From the same family of tools
