Bring your own cloud (BYOC)
With bring your own cloud (BYOC), Hindsight runs as a single-tenant deployment inside your AWS account, Google Cloud project or Azure subscription. Your data stays in your account, and the language model runs on your cloud's own AI service. Vectorize deploys and operates the environment for you through scoped, audited access. This page is for platform and security teams planning a BYOC deployment.
How it works
- You own the account and the data. The cluster, database, storage and model endpoints are all created in your account. You can see every resource, and you can revoke our access at any time.
- Vectorize deploys through a scoped role. You apply a template we provide that creates one deployment role (AWS) or identity (GCP, Azure). It can only manage Hindsight resources, and it creates no compute or data on its own.
- Vectorize operates through audited access. Day-to-day operation goes through Teleport. A Teleport agent inside the cluster dials out to our Teleport proxy, so you open no inbound ports, bastions or public cluster endpoints. Every operator session uses short-lived certificates, requires multi-factor authentication, and is logged with the operator's identity. Access is least-privilege and can be revoked centrally and immediately.
What gets deployed
A self-contained Hindsight instance on your cloud's managed Kubernetes service:
- The Hindsight application (API, workers and UI) and its PostgreSQL database, running in the cluster on dedicated nodes.
- An in-cluster identity service for sign-in. You can connect your own identity provider with SSO.
- An embeddings service on one small GPU node, so embeddings are computed inside your network.
- Object storage in your account for uploaded files and, with Hindsight Memlake, your memory data.
- The language model from your cloud's AI service: Amazon Bedrock, Vertex AI or Azure OpenAI. Inference stays in your account and authenticates with a cloud identity, not an API key.
What you provide
| Item | Details |
|---|---|
| Account | A dedicated AWS account, GCP project or Azure subscription (preferred), or a dedicated network in an existing one. |
| Region | Your preferred region. It must have capacity for the node types we size for you, including a GPU node. |
| Quotas | Compute quota for the node pools and one on-demand GPU node. GPU quota often needs a limit increase, so request it early. |
| AI service | Model access enabled on Amazon Bedrock, Vertex AI or Azure OpenAI for the model we agree on, in your region. |
| Network | Private subnets you create and share with us, or permission for us to create a dedicated VPC or VNet. |
| Outbound access | HTTPS (443) egress to Vectorize's container registry (*.pkg.dev and storage.googleapis.com) and to our Teleport proxy. All required connections are outbound only. |
| An SMTP relay (host, port, credentials and from-address) for verification and invitation emails, or outbound access on port 587 to ours. | |
| Constraints | Anything we must follow: data residency, encryption and key management standards, mandatory resource tags, or your egress approval process. |
What Vectorize provides
- Infrastructure as code. Terraform for the cloud resources and a Helm chart for the application.
- Container images from Vectorize's registry, pulled with a read-only credential we supply.
- DNS and TLS. Hostnames on our domain that point at your deployment's load balancer, with certificates issued automatically. No DNS changes are needed on your side.
- Secrets. All application secrets are managed by Vectorize and injected at deploy time.
- Operations. Deployment, monitoring, upgrades and support. See Operations.
Cloud-specific details
Exact node sizes and storage are sized for your workload during kickoff.
AWS
| Resource | What's created |
|---|---|
| Kubernetes | Amazon EKS with managed node groups for the application (autoscaled), monitoring, the database, and a GPU node for embeddings |
| Database | PostgreSQL in the cluster on its own node group, on encrypted EBS volumes |
| Object storage | An Amazon S3 bucket, accessed through IAM roles for service accounts, with no access keys |
| Language model | Amazon Bedrock, reached through a Bedrock interface VPC endpoint so inference never leaves your network |
| Networking | A VPC with private subnets for nodes, a NAT gateway for outbound traffic and an internal Network Load Balancer |
Deploy access. You deploy a CloudFormation template that creates one IAM
role and its policies, nothing else. Only Vectorize's AWS account can assume it,
and only with an agreed external ID. Regional actions are locked to your chosen
region, and the IAM roles, S3 bucket and log groups it manages are limited to a
hindsight-* name prefix. The deploy role can't invoke Bedrock models; that
permission belongs only to the application's own role. You send us the
DeploymentRoleArn output from the stack.
GCP
| Resource | What's created |
|---|---|
| Kubernetes | GKE with node pools for the application (autoscaled), the database and monitoring, and a GPU node for embeddings |
| Database | PostgreSQL in the cluster on persistent disks |
| Object storage | A Google Cloud Storage bucket |
| Language model | Vertex AI in your project, authenticated with workload identity |
| Networking | A VPC with private subnets and an internal load balancer |
Deploy access. You run a setup script with gcloud, signed in as a
project Owner or IAM Admin. It creates a dedicated deployer service account,
grants it the roles needed to run GKE, and lets Vectorize's principal
impersonate it. Impersonation uses short-lived tokens, so no service account
keys are created or exported. You send us the service account email the script
prints, plus your project ID and region.
Azure
| Resource | What's created |
|---|---|
| Kubernetes | AKS with node pools for the application (autoscaled), the database and monitoring, and a GPU node for embeddings |
| Database | PostgreSQL in the cluster on managed disks |
| Object storage | An Azure Blob Storage account |
| Language model | Azure OpenAI in your subscription, authenticated with a managed identity |
| Networking | A VNet with private subnets and an internal load balancer |
Deploy access. You run a setup script with the Azure CLI, signed in as a subscription Owner (or User Access Administrator plus Contributor). It creates a resource group and a scoped custom role, and assigns that role to Vectorize's service principal on that resource group only. Our access can't reach the rest of your subscription. You send us the subscription ID, resource group and location the script prints. Azure OpenAI access is approved per subscription, so request it early.
Install process
- Kickoff. We agree on the cloud, region, model, connectivity and sizing, and review the access model with your security team.
- Grant deploy access. You apply the CloudFormation template (AWS) or run the setup script (GCP, Azure), then send us the role ARN, service account email or resource group details.
- Confirm prerequisites. You confirm model access, GPU quota, outbound access and your SMTP choice.
- Provision infrastructure. We apply the Terraform to create the network, cluster, node pools, storage and model endpoint, and install the Teleport agent.
- Deploy Hindsight. We install the application with Helm, configure DNS and TLS, and validate retain, recall and reflect end to end.
- Connect. We set up private networking or your IP allowlist, you connect SSO, and we hand over the addresses. See Accessing your deployment.
Networking
BYOC deployments are exposed on a private, internal load balancer by default. The hostname we publish on our domain resolves to a private address, so only clients inside your network (the VPC, or a peered or VPN-connected network) can reach it. From there you can add:
- Private access from other networks. Reach the deployment from other VPCs or accounts with AWS PrivateLink, GCP Private Service Connect or Azure Private Link, with no peering and no internet transit.
- Public access with an IP allowlist. Add an internet-facing endpoint restricted to the address ranges you specify, for example so people can use the UI from your corporate network while application traffic stays private.
See Private networking for the setup steps.
Upgrades
We coordinate every upgrade with you:
- Pinned, validated builds. Your deployment runs an immutable build that has already run on the multi-tenant Hindsight Cloud service. It never follows a floating "latest" tag.
- Controlled schema migrations. Database migrations run as a separate, supervised step before the new version rolls out, so application pods never change your schema on their own.
- Agreed windows. We schedule the upgrade with you, apply it, and verify the deployment afterward.
Data ownership and residency
- All memory data, uploaded files and database backups are stored in your account, in the region you chose.
- Language model inference runs on your cloud's AI service in your account. Embeddings are computed on the GPU node in your cluster.
- Vectorize's access is limited to the deployment role and Teleport. Remove the role or role assignment, or block egress to our Teleport proxy, and our access ends.
- Deleting the infrastructure and then the deployment role's stack or script resources removes Hindsight from your account entirely.
Get started
Book a call or contact your Hindsight representative. A 30–45 minute working session to confirm the region, access model, model access, outbound access and GPU quota unblocks everything else.