DocuPipe,
inside your walls.
Run DocuPipe in your own AWS, Azure or Google Cloud account, or on the Kubernetes cluster in your datacenter. Documents, credentials and results stay on infrastructure you own, and nothing needs to reach the internet.
Two ways to install, one DocuPipe.
Pick the one that matches how your infrastructure is run. Both serve the DocuPipe web app and API from inside your network.
Your cloud account
Send us your account ID and we grant it access to the DocuPipe images. One command then builds the network, database, storage and service inside your account, and runs a real document through before it reports success. A fresh install takes about half an hour.
- Provisioning
- Included, from one command
- Endpoint
- Internal only, with no public listener
- Upgrades
- Rerun the same command
$ ./install.sh \ --target-account-id 123456789012 \ --aws-region us-east-1[install] DONE website / API endpoint (reachable from inside the VPC): http://internal-docupipe-onprem-7f3a.us-east-1.elb.amazonaws.com[install] all green. the bundled e2e invoice + webhook delivery test passed after the final deployment; the deployment is verified and live.
Your Kubernetes cluster
Mirror our images into your registry, fill in one values file, and install with Helm. Storage, CPU or GPU, and your model endpoint are all set in that file. The built-in test sends a document through OCR before your team starts using it.
- Provisioning
- None, it installs into your cluster
- Storage
- The S3-compatible store you already run
- Upgrades
- Change one image reference
$ helm install docupipe ./docupipe-onprem-0.4.8.tgz \ --namespace docupipe --values customer-values.yaml \ --wait --wait-for-jobs --timeout 30mSTATUS: deployed$ helm test docupipe --namespace docupipeTEST SUITE: docupipe-ocr-smokePhase: Succeeded
Built for teams that can’t send a page outside.
Two organizations that run DocuPipe on their own infrastructure: the problem each one had, and what DocuPipe does about it.
Disability claims, read before the assessor opens the file.
A disability claim arrives as one long file: hospital letters, specialist reports, functional assessments and handwritten forms, stacked in no order. Before anyone can decide anything, an assessor has to read all of it, find the few lines that matter under the rules, and work out which sources to trust. Every day spent reading is a day the claimant waits.
DocuPipe reads the file first. It splits the bundle into its documents, pulls out the evidence the rules ask about, such as help with bathing, dressing or walking, and links every finding to its page. It grades each source by who wrote it and how recent it is, calls out contradictions, and drafts the questions for the follow-up call. The assessor opens a brief instead of a pile, and still makes the decision.
- Runs in
- The agency’s own cloud account
- Internet access
- Not required
- In use for
- Redacting personal details from case files
- In pilot
- Disability claim preparation
Chargebacks, invoices and credit reports, in one shape each.
A card processor runs on documents it doesn’t control. Chargeback packets, merchant invoices and credit reports arrive in whatever layout the sender chose, and every one has to become clean fields in systems that accept nothing else. None of it is allowed to leave the building.
DocuPipe runs on the processor’s own Kubernetes, in its own datacenter, with no dependency on the internet. Images come in through its private registry, documents sit in the object storage it already runs, and every model call stays on its network. Each document is mapped to one schema for its type, so a dispute has the same fields whoever sent it, and the teams downstream work from records instead of PDFs.
- Runs on
- Kubernetes in its own datacenter
- Internet access
- Not required
- Images
- Mirrored into its private registry
- Storage
- The S3-compatible object store it already runs
- Model calls
- An endpoint on its own network
Answers for your security review.
How the install is built, in the terms your security team will ask about.
- Network
- Private by default. The cloud-account install sits behind an internal load balancer with no public listener. The cluster install exposes a single Route or Ingress.
- Internet
- Not needed at runtime. The cluster install is designed for air-gapped networks.
- Our access
- None. DocuPipe has no access to your database, your storage or your network.
- OCR and models
- OCR runs inside the deployment. Model calls stay inside your own cloud account, or go to an endpoint you host.
- Privileges
- The cluster install runs under OpenShift’s restricted-v2 policy, binds only ports above 1024, and ships an optional default-deny network policy.
- Secrets
- Credentials stay in your cloud’s secrets manager or in Kubernetes Secrets. On the cloud-account install they are injected at start and never written to disk.
- Images
- On the cluster install, every image is referenced by digest in your values file, and the application image is scanned for vulnerabilities before release. Pull directly or mirror into your own registry.
- Sign-in
- SAML single sign-on is available on the cloud-account install.
- Your documents
- Never used to train or evaluate any model.
What installation looks like.
- 1
We grant access
Send us your cloud account ID, or get pull access to mirror our images into your own registry.
- 2
You run one install
One command in your cloud account. One Helm install and one values file on your cluster.
- 3
It checks itself
The cloud-account install runs a real document through before it reports success. On a cluster, the built-in test does the same.
- 4
Upgrades work the same way
Rerun the command, or change one image reference. Documents, results and credits carry over.
Questions we get from IT.
Does DocuPipe need internet access?
No. Neither install needs the internet at runtime. The cluster install is designed for air-gapped networks: you mirror the images into your registry ahead of time and install from there.
Which clouds and platforms does it run on?
You can install into your own AWS, Azure or Google Cloud account, or onto Red Hat OpenShift or another Kubernetes cluster, including one on bare metal in your own datacenter.
Where do model calls go?
On the Kubernetes install, to the endpoint you set in the values file, on your own network. On the cloud-account install, they stay inside your own cloud account. Either way, no document is sent to DocuPipe.
Do we need GPUs?
No. The Kubernetes install runs on CPU or NVIDIA GPUs, and you choose in the values file.
Is it the same product as the cloud version?
It is the DocuPipe web app and API, served from inside your network, so schemas, extraction and webhooks work the way they do in our cloud. A few cloud features, such as the in-app assistant, are not part of every private install.
How is it priced?
On-prem uses the same credits as our cloud, bought upfront on an annual enterprise agreement.
Bring DocuPipe inside.
Tell us where it needs to run. We’ll send the install package for your cloud account or your cluster.