Private voice AI that installs like enterprise software.
Most voice AI projects do not fail on the model. They fail on packaging, upgrades, private registries, and network constraints — then on the question every platform team asks next: who operates this after go-live? Wordcab is built for that layer.
Four deployment shapes. One product.
Pick the shape that matches the environment your security team will approve. Wordcab ships with reference architectures, Terraform modules, and Helm values for each.
Click the diagram to inspect · scroll or +/− to zoom · 0 to reset
VPC-isolated on managed Kubernetes
The most common production shape. Wordcab runs inside a single VPC on EKS, AKS, or GKE. Every audio byte, transcript, and downstream artifact stays in the customer's cloud account, in-region, inside their own IAM boundary.
- Ships with: Terraform modules for AWS / Azure / GCP, Helm chart, Grafana dashboards
- Typical GPU pool: 2–4× L40S or H100 node group with autoscaling
- Ingress: Private load balancer; PrivateLink / Private Endpoint supported
- Observability: Prometheus + OTel to your existing stack
- Time to first call: ~2 weeks from cluster access
Click the diagram to inspect · scroll or +/− to zoom · 0 to reset
Full on-prem Kubernetes
Physical control. No cloud dependency in the audio path. Wordcab runs on the customer's own cluster (OpenShift, RKE2, vanilla K8s), against internal PBX, internal IdP, internal monitoring. Registry is mirrored locally.
- Ships with: Helm chart, offline bundle, preflight checks
- GPU: On-prem NVIDIA HGX nodes or equivalent
- Telephony: SIP gateway bridges PBX/Avaya/Genesys into Voice
- Identity: Internal AD / LDAP / Keycloak via SAML/OIDC
- Storage: On-prem object store (MinIO) or NFS
Click the diagram to inspect · scroll or +/− to zoom · 0 to reset
Airgap / sovereign
No internet in the critical path. Wordcab ships as a signed offline bundle, imported through the customer's approved transfer channel. Registry mirror, IdP, monitoring, and audit log ship are all internal. The system never phones home.
- Ships with: signed offline bundle (Cosign), KOTS-style preflight, runbook
- Updates: cadence aligned with customer change window; signed tarball
- Identity: internal LDAP / AD / Keycloak with SAML or OIDC
- Audit: streamed to customer SIEM; nothing leaves the boundary
- Use cases: government, sovereign clouds, regulated defense, high-side compartments
Click the diagram to inspect · scroll or +/− to zoom · 0 to reset
Hybrid on-prem + cloud
Real-time voice stays in the datacenter closest to PSTN and user audio. Heavy batch work — overnight archive transcription, fine-tuning, large-LLM reasoning — runs in the cloud on cheaper spot capacity. One control plane, two execution locations.
- Ships with: Helm charts for both sides, shared control-plane config
- Link: DirectConnect / ExpressRoute / private VPN
- Data split: hot transcripts on-prem; cold archives + fine-tuning data in cloud object store
- Use cases: regulated contact centers, financial services with regional data sovereignty, healthcare with on-prem EHR
On-prem is not one environment. It is a packaging problem.
Enterprise buyers treat private deployment as a spectrum: customer-managed Kubernetes, private cloud, restricted networks, air-gapped estates, VMware-heavy environments, mixed hardware fleets.
The slogan is not what matters. What matters is whether the install is repeatable, upgradeable, supportable, and secure by default.
The install has to survive more than day one.
Reproducible across environments
Infrastructure as code, deterministic config, and a deployment model that can be reproduced across customer environments.
The same install produces the same result in every environment. No manual steps. No undocumented config drift. Hand the deployment to another team and it still works.
Safe upgrade paths
Versioned releases, safe upgrade paths, and a rollback story your platform team can live with.
Upgrades should not be a project. Versioned releases, documented migration paths, and rollback procedures that work in production — not just in a vendor demo.
Diagnosable by design
Preflight checks, diagnostics, logs, and support bundles that make troubleshooting possible without guesswork.
Preflight checks catch missing requirements before install. Diagnostic exports and support bundles make troubleshooting possible without vendor SSH access — and without guessing.
Secure by default
RBAC, secrets handling, private registries, custom CA support, and network assumptions that fit real enterprise controls.
Security is not a feature request. RBAC, secrets management, private registry support, custom CA chains, and restrictive network defaults are built in from day one.
The deployment package is part of the product.
First-class Helm packaging
Give platform teams a native install and upgrade path for Kubernetes-based production environments.
Helm charts are the primary packaging format. Values-based configuration, environment overrides, and safe rollout logic that fit how platform teams already manage Kubernetes workloads.
Optional lifecycle automation
Operator-like control patterns where the environment needs stronger lifecycle management for updates, scaling, or multi-service orchestration.
When the environment demands it, automated lifecycle management handles updates, scaling, and service coordination — no manual intervention for routine operations.
Air-gap readiness
Support private registries, offline artifacts, controlled ingress and egress, and environments that cannot depend on open internet access.
No hidden internet dependency in the critical path. Offline bundles, mirrored registries, and controlled artifact flow for environments where egress is restricted or eliminated entirely.
Preflight and support tooling
Catch missing requirements early and make it easier to export diagnostics when something breaks.
Preflight checks validate the environment before install. Support bundles export structured diagnostics — so troubleshooting does not require giving the vendor access to production.
Flexible infrastructure fit
Target CPU, GPU, and selected accelerators based on latency, throughput, economics, and control requirements.
Model serving adapts to the available hardware. CPU, GPU, and accelerator targets are configured per workload — not locked to a single hardware assumption baked into the product.
Private deployment does not have to mean one environment.
Wordcab is built for customer-owned cloud accounts, on-prem clusters, hybrid estates, and mixed hardware pools. Enterprise voice AI rarely stays in one clean environment — teams mix private cloud with on-prem capacity, run different workloads on different hardware, and need one operating model across the estate.
Frequently asked questions
We already proved the workflow with a hosted API. Why is deployment still the blocker?
Why make such a big deal about Helm and packaging?
What if our environment has restricted egress or no direct internet access?
Can we start with a smaller evaluation install before the production path is fully approved?
What will our team still own?
Start with the install path your environment will actually approve.
If your team is reviewing private voice AI for a real production environment, Wordcab maps the deployment target, packages the install path, fine-tunes the stack, and hands over an operating model your team can support.
Talk to an Engineer
We usually respond within one business day.