Read live from Azure Ring n Bring · production only

What production is actually made of

The flow diagram shows how an order moves. This one shows where it runs — the real machines, databases and regions behind qrbring.com, read straight out of the Azure subscription rather than from a design doc. The short version: production is two virtual machines, and one of them is doing almost all of the work.

The short version

01 DNS lives outside Azure qrbring.com is hosted on DigitalOcean and points at two fixed Azure IPs.
02 Ten API hostnames, one machine Every production API resolves to 172.164.224.29 — a single burstable VM in UAE North.
03 The databases sit beside it MySQL, two MongoDB clusters, Redis and Service Bus, all in UAE North.
04 But the main one doesn't Firestore — the primary datastore — runs in Google's us-central1, in Iowa.

That last box is the thing most people are surprised by. The platform is two clouds at once: Azure holds the compute and the supporting databases in the UAE, while the database that actually coordinates every order lives on the other side of the world in Google Cloud. Every order write makes that trip.

The map

Production, drawn to the resource names you'd see in the Azure portal

Drawn the way you'd lay it out in draw.io: every box is a real resource, and the nesting is real — subscription, then resource group, then virtual network, then subnet, the same containment you click through in the portal. Red means a security problem, not just a warning.

The SVG is vector and opens straight in draw.io if you want to edit it.
Ring n Bring — Production Architecture Azure (UAE North) + Google Firebase (us-central1) · resource names read from the Ringnbring Subscription, 12 Aug 2026 Azure resource Google / Firebase Third party Security problem Traffic No authentication Clients Guest PWA rnbresto-emitter · Ionic Admin Portal adminDashboard · Angular 7 Sales Portal salesdashboard · Angular Receiver App Capacitor · staff device Mobile App RN/ · Expo React Native wearOS Watch wearOs App qrbring.com DNS DigitalOcean — outside Azure A records point at the two static Azure IPs Browsers reach Firestore directly Security rules allow read and write with no auth check, so the backend is not in the path at all. Microsoft Azure — Ringnbring Subscription Resource group: ring-n-bring-prod (UAE North) Public IP addresses Standard · static 172.164.224.29 → rnb-backend-prod 20.174.3.52 → rnb-frontend--prod 10 API hostnames share the first Network security group rnb-backend-prod-nsg Rule 370 “Any” — every port, any source, action Allow so the SSH rule at 380 never runs VNet: rnb-backend-prod-vnet — 10.0.0.0/16 Subnet: default rnb-backend-prod Standard_B4ms · 4 vCPU / 16 GB · 10.0.0.4 ~20 pm2 Node processes + ringnbringncare rnb-frontend--prod Standard_B2ms · 2 vCPU / 8 GB · 10.0.0.5 admin portal + sales portal builds MySQL Flexible rnb-infrasys-db-prod Standard_B2s · 20 GB MySQL 8.0.21 public · HA off Cosmos DB (Mongo) rnb-engage- mongodb-prod M10 · 32 GB MongoDB 6.0 public · HA off Cosmos DB (Mongo) mongodb-wearos- db-logs-prod M10 · 32 GB MongoDB 7.0 public · HA off Cache for Redis do-redis-prod- ringnbring Standard C1 Redis 6.0 TLS 1.2 only Key Vault Vault-Prod-Env prod-backup-vault Recovery Services Resource group: defaultrnb Service Bus ringnbring · Standard 7 topics · 8 queues order-management · payment- processing · menu-management infrasys · foodics · simphonygen2 prod-micromenu: 158 messages dead-lettered, unattended Resource group: devops-automation rnb-vmctl-web Static Web App · East Asia vmcontrol.qrbring.com — this console rnb-vmctl-fn Function App · Central India Google SSO + shared password starts / stops dev & QA only Production is not in the TARGET_VMS_JSON allow-list. Cross-cloud: UAE North → us-central1 (~12,000 km each way) Google Cloud / Firebase — project rnb-resto (us-central1) Cloud Firestore the primary datastore every order is one document, and that save is the event rules: allow if true Firebase Auth guest + staff sign-in for the Angular, Ionic and React Native clients Cloud Functions rnbresto-functions 34 exports · Node 22 Firestore triggers for orders and devices Firebase Hosting rnb-resto target the Firestore rules ship from this same project Third parties Point of sale Oracle Simphony Gen1 & Gen2 · Infrasys Foodics · Omega · TOTPOS Payment providers Stripe · PayTabs · CCAvenue · Urway · JCC PayOne · MontyPay · Whish · Network Intl Messaging Twilio WhatsApp to guests Microsoft Graph for email

Two virtual machines carry all of production. Everything to their right and below is something one of them calls — the data services in the same resource group, Google Cloud across the ocean, and the POS, payment and messaging providers. The console you are reading this in is the small box on the right, deliberately scoped to dev and QA only.

The inventory

Every production resource in the subscription, with what it costs you in blast radius

Resource group ring-n-bring-prod, plus the Service Bus namespace that lives in defaultrnb. Read from the Ringnbring Subscription with list-only calls.

ResourceTypeSize / tierRegionRedundancyReachable from
rnb-backend-prodVirtual machineStandard_B4msUAE North single instancethe internet, every port
rnb-frontend--prodVirtual machineStandard_B2msUAE North single instance80, 443, 4201, 9100, 22
rnb-infrasys-db-prodMySQL Flexible ServerStandard_B2s · 20 GBUAE North HA disabledpublic + all Azure IPs
rnb-engage-mongodb-prodMongo clusterM10 · v6.0 · 32 GBUAE North HA disabledpublic
mongodb-wearos-db-logs-prodMongo clusterM10 · v7.0 · 32 GBUAE North HA disabledpublic
do-redis-prod-ringnbringAzure Cache for RedisStandard C1 · v6.0UAE North replicated pairTLS 1.2 only, :6380
ringnbringService Bus namespaceStandardUAE North —SAS
Vault-Prod-EnvKey Vault—UAE North ——
prod-backup-vaultRecovery Services vault—UAE North VM backup—
rnb-ai-foundaryAzure AI Foundry—East US ——
rnb-analytics-prod-ipPublic IPStandard · staticEast US orphanedattached to nothing
monitoring-server-production165_z1Network interfaceholds 172.164.241.208UAE North orphanedno VM behind it

Amber marks something that would hurt during an incident — no second instance, no failover, or a wider network exposure than the service needs. The Redis configuration is the one that is set up the way you'd want the others to be.

How this was produced. The Azure figures come from list-only calls against the Ringnbring Subscription — az vm list, az resource list, az mysql/redis/servicebus … list, az network nsg rule list — on the date stamped at the top of this page. Nothing was created, modified or deleted. Service names, ports, Node versions and deployment behaviour come from bitbucket-pipelines.yml and the service sources in the monorepo at the commit linked above. The Google Cloud side is read from .firebaserc, firebase.json and global-options.ts rather than from a live GCP query, so treat the region and project facts as “what the repository configures” — they are worth confirming in the Firebase console.