Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.grantex.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
Data Residency Statement

Status: Current public disclosure. Subject to legal review. Not a certification document. Last reviewed: 2026-05-24 This page describes where Grantex stores and processes customer data on the hosted offering (api.grantex.dev), and the residency choices available to operators running their own Grantex deployment.

​
Hosted Grantex (api.grantex.dev) — single region today

All production-grade data for the hosted service is currently pinned to Google Cloud us-central1 (Council Bluffs, Iowa, USA). This is sourced from deploy/gcp/setup.sh: 
REGION="us-central1"
SQL_INSTANCE="grantex-pg16"       → us-central1
REDIS_INSTANCE="grantex-redis"    → us-central1
AR_REPO="grantex-images"          → us-central1
CR_SERVICE="grantex-auth"         → us-central1
Data classStorage locationNotes
Agents, grants, audit, commerce recordsCloud SQL PostgreSQL, us-central1Encrypted at rest by GCP (AES-256). Backups stored in the same region.
Rate-limit + idempotency stateMemorystore Redis, us-central1TTL-bound, no long-lived PII.
Container imagesArtifact Registry, us-central1Build artifacts only.
Runtime secretsSecret Manager, us-central1Vault encryption key, JWT signing keys.
Marketing site (grantex.dev)Firebase HostingGlobal CDN edge (Google anycast); origin in US.
DNS recordsCloud DNSGlobal anycast.
Cross-border transfers. Operating the hosted service from us-central1 means that requests originating outside the United States cross a border at request time. Customer payloads are not replicated to other regions by Grantex.

​
EU / India / multi-region availability

A multi-region offering (EU and India) is on the public roadmap (ROADMAP.md, item “Managed Cloud”). It is not available today. Until then:
  • Customers with EU data-residency obligations under GDPR should evaluate the self-hosting option below.
  • Customers with DPDP Act (India) “significant data fiduciary” obligations may require self-hosting to keep data within India. See docs/compliance/dpdp-act-2023.mdx for the technical control mapping.

​
Self-hosted Grantex — operator-chosen residency

Grantex is Apache 2.0 and ships with a Helm chart (deploy/helm/grantex/) and Docker Compose stack (docker-compose.prod.yml). When you self-host, the data never leaves the infrastructure you control — Grantex maintainers receive no telemetry from your deployment by default. Operator-controlled residency knobs:
  • Compute — anywhere your Kubernetes cluster or container host runs.
  • PostgreSQL — point DATABASE_URL at any Postgres 14+ instance in your region of choice.
  • Redis — point REDIS_URL at any Redis 6+ instance in your region of choice.
  • Object storage destination (optional audit export) — choose any S3-compatible bucket region.
  • OpenTelemetry sink (optional) — point OTEL_EXPORTER_OTLP_ENDPOINT at a collector in your region.
See docs/self-hosting.md for the full operator runbook.

​
Backup, retention, and deletion

  • Backups: WAL-archive backups recommended per the Cloud SQL default policy on hosted; operator-defined on self-hosted. A formal backup/restore runbook is TBD as a follow-up doc.
  • Retention: audit-log retention is operator-configurable; defaults documented in apps/auth-service/src/config.ts.
  • Deletion: DPDP erasure flow (/v1/dpdp/data-principals/:id/erasure) and consent withdrawal flows are implemented in apps/auth-service/src/routes/dpdp.ts. Deletion propagates to the consent record, the associated grant, and audit-entry anonymization.

​
Contact

Residency or transfer questions: security@grantex.dev.