Proxaradocs
Guides/Shared platform

On-premise and private deployment

Running inside the firm's own cloud, with the firm holding the keys.

Updated June 2026

Proxara provisions a dedicated, single-tenant AWS account for every pilot and production deployment: one firm, one account, one stack, with the firm holding the encryption keys. No shared multi-tenant plane holds a production firm's data. The free trial and sandbox are the exception; they run on Proxara-operated infrastructure with per-tenant isolation and deletion at the end. This page describes what is inside a firm's account and who can touch it.

The stack

One Terraform composition provisions the same infrastructure for every customer, inside their account and chosen region:

ComponentRole
VPC across three availability zonesNetwork isolation for everything below
ECS FargateRuns the control-plane API
RDS Postgres, Multi-AZ, deletion-protectedThe event and configuration store
S3 with Compliance-mode Object Lock, 7-year retentionThe immutable archive, aligned to SEC 17a-4
ElastiCache RedisQueues and caching
LambdaA scheduled job that re-verifies the signed audit chain
CloudWatch, Route53, ACM, Secrets ManagerOperations, DNS, TLS, and secrets
The firm's AWS accountKMS · firm-held
VPC · 3 AZECS FargateRDS Multi-AZS3 Object LockRedisLocal model in-region
Prompt content stays inside this boundary.
Ops role · revocable
ProxaraOperates · never owns keys
One firm, one account, firm-held keys

Keys and access

Encryption at rest (RDS, S3, EBS, Secrets Manager) runs under KMS keys administered by the customer. Proxara holds use rights for operating the service, and the customer can revoke them; administration of the keys never leaves the firm. Firms that want no Proxara access at all can run the same Terraform themselves in an account Proxara cannot reach, leaving the operations role unset. The stack is identical either way; what changes is who operates it.

Classification stays in the account

The classifier that reads content for sensitive values runs on AWS Bedrock inside the firm's own account, in the firm's region. Content goes from where it originates, the device under Endpoint Protection, or the firm's own Microsoft tenant under Proxara Connect, to the firm's stack to Bedrock in-account and back. It does not transit Proxara infrastructure, and AWS Bedrock does not retain or train on inference content.

Verifiable without trusting the operator

The audit record is built so the firm does not have to take anyone's word for its integrity, including Proxara's. Events are signed at their source, on the device that produced them or by the connector workload that performed them, hash-chained, and archived to the firm's own S3. The offline verifier checks signatures and walks the chain against the registered public keys with no Proxara service in the loop, and the scheduled Lambda job repeats the same check from inside the account. The full verification story is in The console and the Trust Center.

What leaves the account

To Proxara: operational telemetry about the service's own health, and nothing of the firm's AI content. To the model, and only there: the protected form of the work, redacted device traffic under Endpoint Protection or stand-in-protected material to the firm's own AI assistant under Proxara Connect. The Trust Center's subprocessor list is the complete inventory of third parties, and the data-handling documents there state the retention and deletion posture in contract language.

A security team working through its own review of this architecture can start at Security review.