Skip to main content

​
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. Grantex is owned by Orchestrum Technologies LLP; inventor and owner: Sanjeev Kumar.

​
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:
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 designated as Significant Data Fiduciaries under the DPDP Act (India) may be required to keep specified personal data within India where the Central Government specifies it (DPDP Rules 2025 r.13(4), from 13 May 2027); self-hosting is one way to do that. The DPDP Act otherwise restricts transfers only to countries the Government notifies (s.16), not by general localisation. 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. Erasure revokes the principal’s active grants, marks the consent records erased (they are retained as evidence of consent), and, with DPDP_ERASURE_EXPANDED=true, redacts grievance text and deletes stored exports about the principal (otherwise the response lists them as retained); audit entries are retained unmodified, since they form a tamper-evident hash chain.

​
Contact

Residency or transfer questions: sanjeev@orchestrum.in or mishra.sanjeev@gmail.com. Ownership and IP: sanjeev@orchestrum.in, mishra.sanjeev@gmail.com.
Last modified on September 30, 2026