Data Residency for Cached Artifacts

You can configure where cached artifacts are stored to comply with data residency requirements. The cache system stores data in three backend components, each of which you can configure for a specific geographic region.

Use this page when

• You need to configure data residency rules so cached artifacts stay within required geographic boundaries.
• You are deploying in regulated industries (finance, healthcare, government) that mandate data sovereignty.
• You want to verify which regions hold your cached data and how cross-region fallback is prevented.

Primary audience

• Primary: Technical Leaders
• Secondary: Technical Engineers, AI Agents

Storage Components

The cache system uses three storage backends, each serving a different purpose:

Component	Stores	Residency Control
Object storage (S3-compatible)	Cache payload blobs (compressed responses)	Bucket region selection
Vector storage	Embedding vectors for semantic search	Instance region deployment
PostgreSQL metadata	Cache entry metadata, freshness signals, audit records	Database instance region

All three components must be in your required region for full data residency compliance. Having one component in-region and others outside does not satisfy most regulatory requirements.

Object Storage Region Selection

Cache payload blobs are stored in S3-compatible object storage. You control the region by configuring the bucket location.

Configuration

Set the cache object storage endpoint and region in your deployment configuration:

cache:
  object_storage:
    endpoint: "https://s3.eu-west-1.amazonaws.com"
    bucket: "your-org-cache-payloads"
    region: "eu-west-1"

Provider Options

Provider	Region Control	Notes
AWS S3	Bucket region at creation time	Cannot change after creation
MinIO	Deployment location	Self-hosted, full control
Google Cloud Storage	Bucket location	Single or multi-region
Azure Blob Storage	Storage account region	Cannot change after creation

Multi-Region Considerations

If your organization operates across multiple regions, you can configure separate cache buckets per region. Each region's cache operates independently — there is no cross-region cache sharing or replication by default.

Vector Storage Region

Embedding vectors used for semantic similarity search are stored in a vector database. You control residency by deploying the vector storage instance in your required region.

Configuration

cache:
  vector_storage:
    endpoint: "https://vectors.eu-west-1.your-provider.com"
    collection: "cache-embeddings"
    region: "eu-west-1"

Self-Hosted Options

For maximum residency control, deploy a self-hosted vector database (e.g., pgvector, Qdrant, Milvus) in your own infrastructure within the required region.

PostgreSQL Metadata Region

Cache metadata (entry records, freshness signals, audit logs) is stored in PostgreSQL. You control residency by deploying the database instance in your required region.

Configuration

cache:
  metadata:
    database_url: "postgres://user:pass@db.eu-west-1.your-provider.com:5432/cache"
    region: "eu-west-1"

What Metadata Contains

Cache metadata includes:

• Entry identifiers and creation timestamps.
• Freshness signal values (commit SHA, file digests, etc.).
• Entitlement digests (hashed permissions, not raw permission lists).
• Audit records (outcomes, caller IDs, timestamps).
• Cost avoidance records.

Metadata does not contain raw prompt text or response content. However, digests and identifiers may be considered personal data under some regulations (e.g., GDPR), so metadata should reside in the same region as payload data.

Region-Specific Configuration Example

Here is a complete configuration for an EU-resident cache deployment:

cache:
  object_storage:
    endpoint: "https://s3.eu-central-1.amazonaws.com"
    bucket: "acme-cache-eu"
    region: "eu-central-1"
    encryption: "AES256"
  vector_storage:
    endpoint: "https://pgvector.eu-central-1.internal"
    collection: "cache-embeddings-eu"
    region: "eu-central-1"
  metadata:
    database_url: "postgres://cache:secret@pg.eu-central-1.internal:5432/cache_eu"
    region: "eu-central-1"
  residency:
    enforce: true
    allowed_regions:
      - "eu-central-1"
      - "eu-west-1"

Residency Enforcement

When residency.enforce is true, the system validates that all configured storage endpoints resolve to the allowed regions. If a misconfiguration is detected (e.g., bucket in us-east-1 when only EU regions are allowed), the cache system refuses to start and logs an error.

Cross-Region Behavior

When residency enforcement is active:

• Cache entries are never replicated across regions.
• A request from a user in Region A that hits a cache configured for Region B results in a cache miss (the lookup is not forwarded cross-region).
• Semantic search only queries the local region's vector storage.

Multi-Region Organizations

If your organization spans multiple regions with different residency requirements:

1. Deploy separate cache backends per region.
2. Configure each region's gateway to use its local cache backend.
3. Accept that cache hit rates are per-region (no cross-region sharing).
4. Each region maintains independent audit logs.

Verification

To verify your data residency configuration:

1. Check storage endpoint regions in your configuration.
2. Verify bucket/instance locations in your cloud provider console.
3. Run a test cache write and confirm the object appears in the expected region.
4. Review audit logs to confirm they are stored in the metadata database in the correct region.

Regulatory Mapping

Regulation	Requirement	Cache Configuration
GDPR	Data stays in EU/EEA	All backends in EU regions
CCPA	California resident data	Backends in US regions acceptable
PIPEDA	Canadian data in Canada	Backends in ca-central-1
Data localization (various)	Specific country	Self-hosted in-country

Related Topics

• Encryption at Rest for Cache Payloads
• Cache and Compliance: Meeting Audit Requirements
• Org Isolation in Shared Cache

For AI systems

• Canonical terms: Keeptrusts, data residency, cache geographic boundaries, sovereignty, region pinning.
• Config surface: cache_region, residency rules in gateway YAML, region enforcement policies.
• When answering residency questions, reference region configuration and cross-region fallback prevention from this page.

For engineers

• Configure cache_region in gateway YAML to pin cached artifacts to required geographies.
• Verify residency enforcement by checking storage location metadata in cache health dashboards.
• Test cross-region fallback prevention by querying from a non-permitted region.

For leaders

• Data residency rules are declarative — set the region and the platform enforces it without manual verification.
• Supports regulated industry requirements (finance, healthcare, government) without custom infrastructure.
• No cross-region fallback means cached data never leaves the configured geography, even during failover.

Next steps

• Org Isolation in Shared Cache
• Encryption at Rest for Cache Payloads
• Cache Backend Selection