Five reference architectures for deploying DocxIntel on your own infrastructure — components, data flow, GPU placement, intake paths, network boundaries and what belongs in front. Concrete enough to argue with, which is the point.
These are reference targets for a correctly provisioned environment, not contractual guarantees. Every number here is meant to be validated against your own hardware during the Proof of Value.
Each topology uses the same container images, the same Helm chart and the same open-weight models. What changes is node count, failure domain and how the boundary is crossed.
Everything on one host: gateway, orchestrator, GPU services, PostgreSQL, MinIO and the admin console, deployed with Docker Compose or a one-node Kubernetes cluster. Built for diligence, benchmarking and small departmental sites.
The standard production topology. Three control-plane nodes, two or more CPU nodes for stateless services, and a GPU worker pool that scales horizontally. PostgreSQL runs with a synchronous replica, object storage on your existing S3-compatible platform.
RA-02 with the boundary closed. Images live in your internal Harbor or Artifactory, model weights come from the offline bundle on a ReadWriteMany volume, and every Helm value points inward. No pod can reach anything you have not put in front of it.
EKS or AKS in private subnets with no internet gateway. Object storage reached over a VPC gateway endpoint or Azure Private Endpoint, secrets from your cloud KMS, images from ECR or ACR mirrored into your account.
Two full stacks in two failure domains. The primary processes; the secondary holds a warm PostgreSQL standby, replicated object storage and a DocxIntel release pre-installed with GPU workers scaled to zero until they are needed.
The same nine services, the same intake surfaces, the same audit trail and the same field-level traceability. Whatever the topology, every extracted value keeps its page number, bounding box and confidence score.
The topology most production sites land on. Three control-plane nodes carry etcd and the scheduler; a stateless CPU tier runs the gateway, orchestrator, worker pool and admin console; a GPU pool runs layout and OCR, extraction, classification and LLM serving. Each tier scales for a different reason.
Queue depth is the scaling signal that matters. Adding a GPU node adds throughput close to linearly up to the point where your object storage or PDF rendering tier becomes the constraint — which is usually where the interesting capacity conversation starts.
Closing the boundary changes two things and nothing else: where images come from, and how model weights arrive. The service graph, the ports, the storage layout and the API surface are identical to the connected topology.
Licence enforcement is a locally validated offline entitlement file. There is no activation server, no heartbeat and no grace-period lockout to plan around.
A cloud landing zone that satisfies residency review without pretending to be air-gapped. The cluster sits in private subnets with no internet gateway attached, and every dependency it needs is reached over a private path inside your account.
Running inside your own cloud tenancy is data residency, not physical disconnection. If your classification policy requires the latter, RA-03 is the topology to take into review.
Same software in every column. The decision is about failure domains, boundary posture and how much platform capacity your team has to run it.
Minimum nodes
GPU workers
Survives a node loss
Internet egress
Image source
Typical intake path
Best fit
Node counts assume dedicated hardware. On virtualised infrastructure the same topology maps to VMs across separate hosts and datastores — what matters is the failure domain, not the metal.
Everything the platform listens on and everything it talks to. Nothing in this table requires a route to the public internet.
Port numbers are chart defaults and can be overridden in Helm values. The one that cannot be overridden is the outbound internet path, because it does not exist.
Six ways in, five ways out. Every path lands in the same orchestrator queue and produces the same traceable output, so you can mix them without maintaining two pipelines.
Connector coverage for a specific environment is confirmed during the architecture review against the systems you actually run, not against a generic compatibility list. API reference material is published in the product documentation.
The six questions every review asks, and where the answer comes from.
Pick RA-03 if your policy forbids a routable path outward, RA-04 if residency and tenancy are the concern, RA-02 if you simply want it in your own data centre. The software does not change; the evidence you produce for the board does.
Start from monthly page volume and capability mix, size against roughly 1,800 pages per hour per L40S-class GPU, then scale on queue depth. The sizing page shows worked examples from 50,000 to 5 million pages a month.
Choose an intake surface that needs no new credentials — usually a folder or bucket your systems already write to. Results go back to object storage, a webhook or a database schema you define, so nothing new sits between DocxIntel and your line-of-business system.
OIDC or SAML at the edge with group claims mapped to roles, row-level access on review queues, and an append-only audit trail covering every view, edit, export and administrative action. The audit trail exports to your SIEM in JSON.
A GPU node failure re-queues in-flight page tasks and processing continues on the remaining pool. A control-plane node failure is absorbed by the quorum. A site failure is RA-05 territory, with a warm standby and a scripted, reversible failover.
Signed images with a CycloneDX SBOM per image, cumulative releases so a long-offline cluster upgrades in one step, and an 18-month support window per LTS release. Your team rehearses the first upgrade with us and owns every one after that.
The specifics that decide whether a design gets signed off, answered without hedging.
No. Internal service-to-service traffic uses mutual TLS with certificates issued by the chart at install time, so you get encrypted east-west traffic without adding Istio or Linkerd. If you already run a mesh, the services register normally and you can hand certificate issuance to the mesh instead — both configurations are supported.
