Can You Run OCR Without Sending Documents to the Cloud?

Yes, but the options are narrower than the market implies. Of the three hyperscalers only Microsoft publishes containers you can run on your own hardware, and even those must connect out to Azure to report billing. AWS Textract and Google Document AI have no on premise deployment at all. The genuinely disconnected route is hosting an open-weight model on your own GPU, which costs $587.50 a month before a single page is read.

The question usually arrives from a security questionnaire rather than from an engineer, and the answer depends heavily on which version of it is being asked. "Documents must not leave our network" and "documents must be processed under a signed agreement in a named region" sound similar in a meeting and lead to completely different architectures, with roughly a quarter of engineering time between them. Sort that out first.

Which OCR vendors actually run on your own hardware?

That table is the whole market in five rows, and the second and third rows are the ones that end most projects. If your requirement is that documents never touch a third party's hardware, two of the three biggest OCR services cannot meet it at any price. There is no enterprise tier that unlocks it.

Are Azure Document Intelligence containers air gapped?

No, not as documented. 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 will not start unless the EULA, Billing endpoint and ApiKey values are all supplied. Your documents stay inside the network, which is usually the actual requirement. The meter still calls out, which means the deployment cannot be dropped into a segment with no egress.

For most regulated buyers that distinction is fine and the containers solve the problem. For anyone whose requirement is genuinely a disconnected environment, it is the sentence that decides the project, and it is worth confirming the arrangement with Microsoft in writing before planning around it rather than discovering it during implementation.

Why does on premise Azure extraction run older models?

Because the container releases lag the cloud service, and by more than most buyers expect. The v4.0 container release supports Read and Layout only. Invoice, Receipt and ID Document containers are the v3.1 release that went generally available in July 2023. Custom models and General Document are the v3.0 release from August 2022.

So the moment your requirement moves from plain text to structured invoice extraction, running Azure on your own hardware means running a model that is two to three years behind the one the cloud endpoint serves. That is a real accuracy difference on hard documents, and it appears nowhere near the word container in the marketing. We put the full version matrix and the host sizing on our on premise OCR software page.

What does it cost to keep documents on your own servers?

Two different answers, because the two approaches bill in completely different units.

Vendor containers still bill per page through the connected cloud resource, so the unit cost is broadly the cloud rate and you add the servers. Azure's containers are CPU workloads rather than GPU, asking for 8 cores and 10 to 16 GB of memory each with 24 GB recommended, which is a pleasant surprise. Watch the dependency chain though: the Invoice container requires the Layout container alongside it, so an on premise invoice pipeline is two containers before you process anything.

A self hosted open model bills in GPU hours instead, and that changes the shape of the problem entirely. The cheapest adequate AWS card is $0.8048 an hour, which is $587.50 a month running continuously, and it bills every one of those hours whether documents arrive or not. Against a $1.50 per 1,000 pages managed API, break-even lands around 391,700 pages a month. The per-card arithmetic is on our self hosted OCR cost reference, and the best known open model is costed out specifically on the olmOCR pricing page.

Do you actually need on premise, or do you need a signed agreement?

This is the question worth an hour before anything else, because a large share of on premise projects begin with a phrase in a questionnaire and finish six months later having rebuilt something a data processing agreement already covered.

Go and read the obligation itself rather than the summary of it. Most policies in banking, insurance and healthcare ask for a defined set of things: a signed agreement with the processor, stated data residency, encryption in transit and at rest, role-based access, bounded retention and audit evidence. Every one of those is satisfiable by a cloud vendor under contract. Teams that map their obligations to specific controls rather than to vendor categories usually find the list is shorter and more satisfiable than the internal folklore suggested.

On premise becomes genuinely non-negotiable in four situations: a client contract states documents may not be transmitted to a third party, a classification level forbids the data crossing a boundary at all, the site has restricted or intermittent connectivity, or a regulator has said so in writing about your specific case. Notice that only one of those is a regulation. The most common real driver is a clause in somebody else's contract, and no architecture argument moves it.

Is self hosted OCR more secure?

It is more controlled by definition, and more secure only if you do the work that control implies. Removing a vendor from the data path also removes everything that vendor was doing: patching, key rotation, access logging, retention enforcement, vulnerability management and producing the evidence an auditor asks for. Those all become your team's work, on top of running an inference server.

A self hosted deployment that nobody has time to patch is not more secure than a SOC 2 vendor whose full-time job is patching it. That is not an argument against on premise, which is often exactly right. It is an argument for counting the ongoing operational commitment as part of the security decision rather than treating the network boundary as the whole of it.

The practical middle ground

Most teams land in one of three places. If the obligation is contractual and absolute, run containers or an open model in your own network and accept the older models and the operational load. If the obligation is about residency, encryption and accountability, a cloud product under a signed agreement satisfies it and costs a fraction. If you are not sure which you have, find out before you rent a GPU, because that single answer is worth more than every price comparison on this page.

DocuOCR sits squarely in the second case and it is worth saying so plainly rather than hedging. It is a cloud product, processing documents under US data handling with encryption in transit and at rest, role-based access, retention controls and a data processing agreement. If your requirement is genuinely that nothing leaves your network, we are not the right fit. If your requirement is a defensible answer to a security review, the fastest next step is to run one non-sensitive document through it and see whether the extraction quality justifies the architecture conversation at all.