Backend
NestJS (TypeScript) services on a Prisma ORM and pnpm/Turborepo workspace. PostgreSQL is the primary OLTP store; Valkey/Redis handles cache, sessions, and BullMQ queues; MongoDB Atlas powers AI vector search.
TECHNOLOGY
How Tanqory is built.
An overview of the technologies, infrastructure, and observability stack that powers the Tanqory platform. Sourced from our internal infrastructure registry, not marketing copy.
The stack, at a glance
Tanqory ships four product surfaces — admin web, store web, native iOS, native Android — backed by an infrastructure footprint designed for multi-cloud, multi-region deployment. Every layer below is reviewed quarterly against the source-of-truth registry.
Frontend (web)
Next.js 16 with Turbopack, React 19, TypeScript 5, Tailwind 4. Server Components by default; ISR for content-heavy surfaces; static prerender for launched locales.
Mobile
Native iOS in SwiftUI / Swift 6 (Xcode 16+, min iOS 17, target 18+) and native Android in Kotlin + Jetpack Compose (min SDK 24, target SDK 36). On-device LLM where the platform supports it.
Infrastructure
DigitalOcean primary, Google Cloud and AWS secondary, Cloudflare at the edge. Four business regions: Asia Pacific, Americas, Europe, Middle East and Africa.
Backend
Tanqory's backend is a set of NestJS services in a TypeScript monorepo. Schemas, queues, and the AI service are wired against managed databases — no self-hosted database servers in production.
NestJS (TypeScript)
Admin API, Store API, AI Service. Shared validation, authentication, and observability middleware across services.
PostgreSQL (managed)
Primary OLTP store across seven schemas — Central (auth, billing, provisioning), Store, Policy, Theme, Tax, VM, and Analytics. DigitalOcean Managed PostgreSQL with provider-managed AES-256 at rest and sslmode=require in transit.
MongoDB Atlas
Vector search (1536-dim, OpenAI text-embedding-3-small) and document storage for the AI service only. Hosted on AWS ap-southeast-1 Singapore by default.
Valkey / Redis
DigitalOcean Managed Valkey/Redis (HA pair in production). Cache, sessions, and BullMQ queue backing.
Prisma ORM
Schema-first ORM across services. Migrations gated by review and applied via the deploy pipeline, not by hand.
pnpm + Turborepo
Monorepo workspace with cached, parallelised builds across 18 apps and 11 shared packages.
Frontend (web)
Tanqory's web surfaces — admin, store, marketing, and the Trust Center you are reading now — share a Next.js 16 baseline with strict TypeScript and Tailwind 4.
Next.js 16 (Turbopack)
App Router with Server Components by default. Per-app prerender + ISR policy.
React 19
Concurrent rendering, server actions, and useOptimistic for write-heavy admin flows.
TypeScript 5
Strict mode across all apps. Shared types live in `@tanqory/*` workspace packages.
Tailwind 4
Utility-first styling with shared design tokens. No CSS-in-JS runtime in production bundles.
Mobile
Tanqory ships first-party native apps on iOS and Android. Both rely on the platform's on-device LLM where supported, falling back to cloud inference via the AI service.
iOS
Native SwiftUI, Swift 6, Xcode 16+
Minimum iOS 17, target iOS 18+
- -On-device LLM via FoundationModels framework on iOS 26+
- -Stripe iOS SDK with PaymentSheet and Apple Pay
- -APNs for push notifications
Android
Native Kotlin with Jetpack Compose
Minimum SDK 24, target SDK 36
- -On-device LLM via AICore (Gemini Nano) on supported devices
- -Stripe Android SDK with PaymentSheet and Google Pay
- -Firebase Cloud Messaging for push notifications
Infrastructure
Tanqory operates an infrastructure footprint designed for multi-cloud, multi-region deployment. The table below reflects the four business regions and the cloud providers wired against each. Customer data is processed and stored in the business region assigned to the merchant at sign-up. Multi-region active-active failover is not currently in production; cross-region failover is on the resilience roadmap, owned by Engineering.
| Business region | DigitalOcean | Google Cloud | Amazon Web Services |
|---|---|---|---|
| Asia Pacific | sgp1 (Singapore) | asia-southeast1 (Singapore) | ap-southeast-1 (Singapore) |
| Americas | nyc1 (New York); sfo3 (San Francisco) | us-central1 (Iowa); us-east1 (South Carolina) | us-east-1 (N. Virginia) |
| Europe | fra1 (Frankfurt); ams3 (Amsterdam) | europe-west1 (Belgium); europe-west3 (Frankfurt) | eu-west-1 (Ireland); eu-central-1 (Frankfurt) |
| Middle East Africa | lon1 (London, used as MEA proxy) | me-central1 (Doha, Qatar) | me-south-1 (Bahrain); af-south-1 (Cape Town) |
Cloud roles
Primary compute and database
DigitalOcean
DOKS (Kubernetes), Managed PostgreSQL (HA + read replica), Managed Valkey/Redis (HA pair), Spaces (S3-compatible), Container Registry.
Secondary compute
Google Cloud Platform
Compute Engine and GKE for per-region pods where required by contract or workload.
Secondary compute and storage
Amazon Web Services
EC2, S3 (theme assets), and RDS PostgreSQL where customer contracts require AWS-only data residency.
Edge and DNS
Cloudflare
Authoritative DNS for tanqory.com, CDN, WAF, API Shield, automatic DDoS protection, R2 object storage, and Workers.
AI vector database
MongoDB Atlas
Vector search and document storage for the AI service only. Default region: AWS ap-southeast-1 Singapore.
Encryption stack
Encryption claims map to the encryption section of the infrastructure registry. The list below is verified live; we do not claim controls we have not implemented.
In transit
TLS 1.2+ everywhere, with TLS 1.3 preferred at the edge. Cloudflare Universal SSL on every public hostname; ACME certificate issuance via Let's Encrypt. mTLS between selected internal services. PostgreSQL connections enforce sslmode=require.
At rest (database and storage)
Provider-managed AES-256 on DigitalOcean Managed PostgreSQL volumes and MongoDB Atlas. Cloudflare R2 server-side encryption on primary object storage.
At rest (application layer)
AES-256-GCM for TOTP secrets, OAuth tokens, and payment-provider credentials. AES-256-CBC for SSL private keys. Key material is delivered from Infisical, never embedded in deploy manifests.
File scanning
Customer-facing file uploads in admin-api and store-api are scanned with clamscan before they are written to durable storage.
Observability and on-call
We instrument every production service for errors and performance, and we publish operational status on a separate hostname so customers can see incidents independently of the platform itself.
Error and performance monitoring
Sentry across backend (NestJS), web (Next.js), and mobile (iOS, Android). Source maps and release tagging on every deploy.
Public status page
status.tanqory.com is the canonical operational status surface for customers, separate from the marketing site.
On-call rotation
Engineering operates a 24x7 on-call rotation for production incidents. A dedicated, in-house 24x7 SOC is on the security roadmap but is not in production today — we say so explicitly.
Secrets management
Tanqory runs a self-hosted Infisical instance at secrets.tanqory.com. Secrets are delivered into Kubernetes via the Infisical Secrets Operator, surfaced as native Kubernetes Secret objects, and re-rolled by Reloader when a value changes. No static long-lived credentials are baked into deployment manifests.
- -Self-hosted, in scope of Tanqory's own ISMS — not a third-party hosted secrets vendor.
- -Credential rotations propagate to workloads without manual pod restarts.
- -Production access to secrets is gated by least-privilege roles with audit logging; full enforcement audit (formal quarterly access reviews with retained evidence) is on the roadmap. Owner: Engineering, with Security oversight.
CI / CD
Builds happen on Buildkite. Delivery is GitOps via ArgoCD against the tanqory-platform-deploy repository. Container images live in DigitalOcean's container registry.
Build
Buildkite pipelines. Lint, type-check, unit tests, and container image build run on every pull request.
Delivery
ArgoCD GitOps reconciles the live cluster state against the tanqory-platform-deploy repository. No imperative kubectl applies in production.
Container registry
registry.digitalocean.com/tanqory-prod is the canonical production image registry.
Common questions about our technology stack
What cloud providers does Tanqory use?
DigitalOcean for primary compute and managed databases; Google Cloud and Amazon Web Services as secondary compute and for AWS-residency-pinned contracts; Cloudflare at the edge for DNS, CDN, WAF, DDoS, R2 object storage, and Workers; MongoDB Atlas for the AI vector database. See the Subprocessors page for the full third-party list.
Is customer data encrypted in transit and at rest?
Yes. TLS 1.2+ (prefer TLS 1.3) on every public endpoint, with Cloudflare Universal SSL and Let's Encrypt certificate issuance. Provider-managed AES-256 at rest on Managed PostgreSQL and MongoDB Atlas; Cloudflare R2 server-side encryption on object storage; AES-256-GCM for application-layer secrets such as TOTP, OAuth tokens, and payment-provider credentials.
Where is my data stored?
In the business region assigned to your account at sign-up — Asia Pacific, Americas, Europe, or Middle East and Africa. The full region map and per-cloud breakdown is on the Regions page.
Do you run multi-region failover?
Not yet. Production today runs in a single region per business region. Multi-region active-active failover is on the resilience roadmap, but we do not claim it as a live control. The DR runbook targets a 1-hour RTO and 1-hour RPO with semi-annual drills.
What is your CI/CD process?
Buildkite for builds with lint, type-check, unit tests, and image build on every pull request. ArgoCD reconciles the live cluster state against the tanqory-platform-deploy repository — no imperative kubectl applies in production. Images live in DigitalOcean's container registry.
Can I see the tech stack in more detail under NDA?
Yes. Enterprise prospects can request a Trust Pack — control mapping, current DPA template, infrastructure detail, and a security questionnaire — by emailing trust@tanqory.com.
Need a deeper technical review?
Enterprise security and procurement teams can request our security questionnaire, current DPA template, and a technical-architecture briefing under NDA.
Email the Trust team