Skip to main content
Caveman Cloud offers three deployment shapes: a fully hosted managed gateway, a customer-owned install in your AWS or GCP account, or an on-premises deployment. All three run the same signed release and the same Helm chart. Your choice determines where data lives, who holds the keys, and who operates the infrastructure.

​
Deployment shapes at a glance

​
Hosted Cloud

Hosted Caveman Cloud is the fastest path to value. You create a project, generate an API key, and swap the base URL. Caveman operates the gateway, control plane, telemetry store, and web console on GCP europe-west4 with ClickHouse Cloud in the same region, behind Cloudflare.

​
Data handling

  • Request and response bodies are kept by default, redacted and envelope-encrypted under AES-256-GCM with a per-object data key wrapped by Cloud KMS.
  • Switch Raw payload storage off in Governance > Data to keep metadata only.
  • Any request can send x-cave-retention: metadata or x-cave-retention: zdr to override retention for that call.
  • Enterprise traffic is never used to train Caveman’s models. Free and pay-as-you-go plans have tier-conditioned defaults.

​
Subprocessors

The authoritative list is at caveman.so/legal/subprocessors. Key parties include Google Cloud (compute, storage, KMS), ClickHouse Cloud (telemetry), and Cloudflare (TLS and DDoS protection). Your model providers are your own processors, not Caveman subprocessors, because traffic reaches them with your key under your agreement.

​
Backups

  • Cloud SQL: daily backups, 30 kept in production, plus 7 days of point-in-time recovery logs.
  • Memorystore Valkey: daily backups, 30 days in production.
  • ClickHouse Cloud: 7 days in production.
  • Portable export: locked GCS bucket with a 30-day retention lock, deleted the day after.
See Data and Privacy for retention controls and deletion behavior.

​
Customer-owned: your VPC on AWS or GCP

The customer-owned install runs the full stack in your AWS or GCP account, operated by Caveman under a separate agreement. You bring your own PostgreSQL, Valkey, and object store. ClickHouse runs either in-cluster or as an external endpoint you manage.

​
Infrastructure

Terraform roots are provided for AWS and GCP private installs: One Helm chart deploys the application. The installer is a signed release archive; no source checkout or build is required. You provide a small site.yaml for admin CIDRs, identity-provider origins, and ingress TLS Secret names.

​
ClickHouse placement

Set clickhouse_placement to decide where ClickHouse runs:
  • in-cluster (default for customer installs): one replica in your cluster, TLS on 8443, daily backups to your own bucket. Requires a node with 3 allocatable CPU and 10Gi memory, plus an expandable StorageClass.
  • external: any ClickHouse you run privately, such as ClickHouse Cloud BYOC in your account. Set external_clickhouse with hostname, private IPv4, port, admin user, and optional SNI and CA.
Switching placement after install is refused until a separate migration is planned.

​
Key custody on customer installs

Stored provider keys are off by default on customer installs. The operator sets providers.storedCredentialsEnabled: true to allow storing team keys sealed under your KMS. Without stored keys, traffic must send x-cave-upstream-key per request. Provider secrets are never returned to clients and never logged in plaintext.

​
Data collection switch

An operator can set dataCollection.enabled: false in the site values to keep the entire installation metadata-only. In this mode:
  • No request content is kept anywhere (captures, compression originals, SDK artifacts, response cache, shared contexts, OTLP log bodies).
  • Compression and the exact response cache are disabled for every organization.
  • Bodies already kept expire with their window.
  • Enterprise and customer installs never share data for training.

​
Private agent execution

Native agent execution (the Factory and Sentinel agents) remains disabled until its private backend is qualified. The chart accepts the agent configuration keys, but agent workloads refuse to start until the backend passes qualification.

​
Backups on customer installs

Your backups are your own. Terraform provisions:
  • RDS or Cloud SQL backups to your retention policy.
  • Valkey daily snapshots to your bucket.
  • In-cluster ClickHouse backups to your own bucket via workload identity or IRSA.
The retention worker enforces organization-deletion and window-based purges daily, but backup copies age out on your schedule.

​
On-premises

On-premises deployment uses the same signed release and Helm chart, running in your datacenter on your bare metal or virtualized Kubernetes. You supply:
  • A Kubernetes cluster
  • PostgreSQL, Valkey, and an S3-compatible object store
  • Your own ClickHouse (in-cluster or external)
  • Your KMS for envelope encryption
The installer expects the same platform.json and site.yaml inputs. Operational telemetry stays in your ClickHouse. Air-gapped operation is not implied by the dedicated offer; contact us to discuss the exact boundary.

​
Local-only tools

The caveman CLI and local proxy (caveman start / wrap) run on your own machine with no account. They compress traffic BYOK and stay inferred-only (no verified savings). Prompts and responses go from your machine to your provider. The CLI sends usage telemetry to Caveman by default, which you can disable with caveman telemetry off or CAVEMAN_TELEMETRY=0. Coding-agent routing: Caveman gets a routing ask, not the request. Traffic goes to your provider with your key. If Cloud is unreachable, local tools keep working.

​
Comparison matrix

​
How to choose

  • Choose Hosted Cloud if you want the fastest setup, do not need data in a specific region, and prefer Caveman to operate the infrastructure.
  • Choose Customer-owned if you need data in your own cloud account, your own KMS, or your own backup regime. This is the standard Enterprise offer.
  • Choose On-premises if you need physical control of the hardware and network, or if regulatory requirements forbid hosted or cloud-managed infrastructure.
  • Use Local tools for individual development, privacy-sensitive experiments, or as a fallback when Cloud is unreachable.

​
Talk to us

Every Enterprise deployment is scoped to your account, region, access, backups, and deletion responsibilities. The agreement identifies each. Legal documents (DPA, Terms, Privacy Policy) are drafts; request current versions from contact@caveman.so.

Book a conversation

Discuss your workload, region, and compliance requirements with our team.

Security Review

Architecture, encryption, tenant isolation, and honest compliance status.

Engineering Leaders

Governance, risk model, vendor neutrality, and pilot checklist.

Data and Privacy

Retention, consent, encryption, and deletion controls.