Private Cloud Deployment Details (Enterprise only)

Sapience can be deployed as a fully self-hosted solution within your own private cloud or on-premises data center. This guide is for IT leaders, security teams, and infrastructure architects evaluating Sapience for environments where data sovereignty, regulatory compliance, and network isolation are non-negotiable.

When you deploy Sapience in your own infrastructure, no data leaves your network. There are no callbacks to Sapience Cloud, no telemetry, and no shared infrastructure with other customers. You own and control every layer of the stack.

e

Sapience runs on Kubernetes and is composed of five containerized services that work together as a single platform. All containers are provided as standard OCI-compliant images and are orchestrated via Kubernetes manifests (Helm charts available).

Sapience requires Kubernetes (v1.26+) for orchestration. This is not optional — the platform relies on Kubernetes-native features for:

Any conformant Kubernetes distribution is supported: AKS, EKS, GKE, OpenShift, Rancher, or bare-metal K8s.

Sapience is composed of five containers, each with a single responsibility. Only one service is exposed externally — the rest communicate exclusively over the internal cluster network.

The primary API and business logic service. This is the only container that handles external traffic.

The application server handles all user-facing API requests, manages authentication and authorization (JWT-based), orchestrates AI agent interactions, and coordinates with the other four services over the internal network.

Networking: Place behind your ingress controller (NGINX, Traefik, or cloud-native) with TLS termination. All other services should be unreachable from outside the cluster.

Handles optical character recognition (OCR) and text extraction from uploaded documents such as PDFs, scanned images, Word documents, and spreadsheets.

This service supports multilingual OCR across English, Arabic, Chinese (simplified and traditional), Spanish, French, German, Italian, Japanese, Portuguese, and Russian. Documents are processed in-cluster and extracted text is passed back to the application server — no document content is transmitted externally.

Creates formatted business documents (presentations, spreadsheets, reports) on behalf of AI agents.

The document generation service receives structured instructions from the application server and produces professional-grade documents. Generated files are written to shared persistent storage, where the application server retrieves them for delivery to users.

Authentication: This service authenticates all requests using short-lived JWT tokens issued by the application server. Even within the cluster, inter-service communication is authenticated.

PostgreSQL serves as the primary data store for all application data including user accounts, organizations, agent configurations, conversation history, audit logs, and access control policies.

You may use the containerized PostgreSQL image provided, or connect Sapience to your existing managed PostgreSQL service (AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL, or your own HA cluster). PostgreSQL 17+ is required.

Backup and recovery: Sapience does not manage database backups. You are responsible for implementing backup, point-in-time recovery, and disaster recovery strategies appropriate for your environment and compliance requirements.

An in-memory data store used for session management, rate limiting, real-time state, and performance caching.

You may use the containerized cache image provided, or connect Sapience to your existing managed Redis-compatible service (AWS ElastiCache, Azure Cache for Redis, Google Memorystore). Redis 7+ is required.

The Application Server and Document Generation Service share a Persistent Volume for file handoff. This is how generated documents (presentations, spreadsheets) are passed from the generation service back to the application server for delivery to users.

Important: Only these two services need access to the shared volume. The document processing service, database, and cache do not require shared storage.

While Sapience runs entirely within your infrastructure, AI agent functionality requires API access to large language model providers. At least one of the following must be provided for the AI system-parts to work:

You provide your own API keys. Sapience does not proxy through any Sapience-operated infrastructure. API calls go directly from your cluster to the model provider.

If your security requirements prohibit any outbound internet access, Sapience supports integration with self-hosted LLM endpoints that expose an OpenAI-compatible API. This includes:

Contact the Sapience team for guidance on configuring air-gapped LLM connectivity.

Deploying Sapience in your own infrastructure gives you complete control over every security layer. Here is how each concern maps to your environment:

Sapience's private cloud deployment model supports compliance with:

For a detailed breakdown of Sapience's data handling practices, see Sapience Data Security, HIPAA & GDPR.

Minimum recommended resources for a production private cloud deployment:

These are starting-point recommendations. Scale the Application Server horizontally and the Database vertically as your user count grows.

Use this checklist when planning your private cloud deployment:

Yes. Sapience supports connecting to any PostgreSQL 17+ or Redis 7+ instance. Simply configure the connection strings in the environment variables. Many customers use managed database services (RDS, Cloud SQL, Azure Database) for production deployments.

Sapience supports air-gapped deployment when paired with a self-hosted LLM endpoint that exposes an OpenAI-compatible API. All container images can be loaded from a private registry with no internet access required at runtime.

Sapience provides updated container images on a regular release cadence. You pull new images to your internal registry and roll them out on your schedule using standard Kubernetes rolling update strategies. There is no automatic update mechanism — you control when and how updates are applied.

The Application Server exposes health check endpoints (/startup, /health) compatible with Kubernetes probes. Application logs are written to stdout/stderr in structured format, compatible with any log aggregation system (ELK, Splunk, CloudWatch, etc.). You are responsible for integrating with your monitoring stack.

Yes. Sapience has built-in multi-organization support with role-based access control. Users, agents, data sources, and conversations are scoped to organizations. A single deployment can serve multiple isolated tenants.

Have questions about private cloud deployment? Contact the Sapience team at sales@sapiencecloud.ai for a deployment planning session.