Celestial Vibe: Proposed Azure Architecture and Cost Assessment

Assessment date: 28 August 2026

Pricing basis: provisional East US primary region and East US 2 recovery region, USD public pay-as-you-go pricing, and monthly Cloudflare billing

1. Celestial Vibe

Celestial Vibe is a multi-tenant performance, process-intelligence, and continuous-improvement platform. It helps organizations connect business data, understand performance, document how work is performed, identify improvement opportunities, prioritise changes, manage delivery, and track results in one connected system. Multi-tenant means that multiple customer organisations use the same cloud application while their users, data, documents, and AI context remain separated.

The product supports this connected workflow:

connect business data → monitor performance → investigate causes and evidence → create an opportunity → prioritise it → manage delivery → track the result

• Measure Performance tracks business and operational metrics, targets, trends, contributing factors, and supporting evidence. It is an extensible framework: available metrics can expand as customer needs, connected data, and analytical requirements grow.
• Process Intelligence turns uploaded documents, recorded voice notes, live discussions, and structured templates into editable process-map drafts.
• Impact–Effort Matrix compares opportunities by expected benefit and required effort.
• Manage Execution converts selected opportunities into assigned work with owners, dates, progress, and tracked outcomes.
• Opportunity Lifecycle connects the original finding and evidence to prioritisation, delivery, and measured results.

The cost assessment compares three independent one-year operating cases:

• Initial Production is the first production tenant, not a temporary development environment.
• Standard Operations represents five production tenants and a moderate shared workload.
• Scaled Operations represents ten production tenants with heavier document, ERP, storage, and speech usage.

These are internal planning scenarios, not standard Microsoft, Azure, or ISV programme tiers.

Launch year means fixed capacity is available for all 12 months while variable usage grows evenly from near zero to the target. Steady-state year means the target tenant, user, and workload levels operate for all 12 months. These definitions apply throughout the report.

Every case includes separate development, staging, and production environments. Development and staging add 15% to variable consumption, use smaller scheduled resources, and rely on backups rather than production-style regional disaster recovery.

Scaled Operations deliberately represents fewer, heavier customers rather than many low-usage customers.

The architecture supports multiple cloud ERP products through vendor-specific adapters. An adapter converts a particular ERP's format into the common format used by Celestial Vibe. Each tenant initially connects one primary ERP using read-only access, so Celestial Vibe can retrieve approved information but cannot change ERP records. Onboarding imports up to 24 months of history; daily incremental imports follow, with faster event notifications where the ERP supports them. Raw imports are retained for 90 days, while selected searchable records are retained for 36 months. ERP licences, vendor API charges, and adapter implementation labour are excluded.

2. Proposed production architecture

The Next.js application is the frontend. It also contains a small backend for frontend (BFF): server-side endpoints tailored to the browser. The planned Node.js service is the main application backend and performs tenant authorization, permanent data access, integrations, work coordination, and protected AI and speech calls.

The diagram shows production components and their relationships, not a step-by-step flow. Each duplicated service is shown separately. Development and staging are smaller separate environments and are intentionally omitted to keep the architecture readable.

---
config:
  layout: elk
  theme: base
  themeVariables:
    fontFamily: "Inter, Segoe UI, Arial, sans-serif"
    fontSize: "18px"
    background: "#1f2329"
    clusterBkg: "#27313d"
    clusterBorder: "#64748b"
    primaryTextColor: "#0f172a"
    secondaryTextColor: "#0f172a"
    tertiaryTextColor: "#0f172a"
    lineColor: "#526174"
    edgeLabelBackground: "#1f2329"
    titleColor: "#ffffff"
  themeCSS: |
    .cluster rect { fill: #27313d !important; stroke: #64748b !important; }
    .icon-shape { background-color: transparent !important; }
    .icon-shape p { background-color: transparent !important; color: #ffffff !important; padding: 0 !important; }
    .icon-shape .label rect { fill: transparent !important; stroke: none !important; opacity: 0 !important; }
    .cluster-label span, .cluster-label text { color: #ffffff !important; fill: #ffffff !important; }
    .edgeLabel, .edgeLabel p, .edgeLabel span { background-color: transparent !important; color: #ffffff !important; fill: #ffffff !important; }
    .edgeLabel rect { fill: transparent !important; stroke: none !important; opacity: 0 !important; }
---
flowchart TB
    subgraph access["Customer Access and Identity"]
        direction LR
        browser@{ icon: "mdi:web", form: "rounded", label: "Customer web browser", pos: "b", h: 56 }
        edge@{ icon: "mdi:shield-check", form: "rounded", label: "Cloudflare CDN, WAF and DDoS protection", pos: "b", h: 56 }
        web@{ icon: "mdi:application-brackets-outline", form: "rounded", label: "NextJS frontend and browser-facing BFF", pos: "b", h: 56 }
        entra@{ icon: "mdi:account-key-outline", form: "rounded", label: "Microsoft Entra External ID", pos: "b", h: 56 }
        browser --> edge --> web
        browser --> entra
    end

    subgraph primary["Azure Primary Production Region"]
        direction TB

        subgraph private_entry["Private Application Entry"]
            direction LR
            tunnel1@{ icon: "mdi:vpn", form: "rounded", label: "Tunnel connector 1", pos: "b", h: 56 }
            tunnel2@{ icon: "mdi:vpn", form: "rounded", label: "Tunnel connector 2", pos: "b", h: 56 }
            ingress@{ icon: "mdi:server-network", form: "rounded", label: "Container Apps internal ingress", pos: "b", h: 56 }
            tunnel1 --> ingress
            tunnel2 --> ingress
        end

        subgraph processing["Application and Background Processing"]
            direction LR
            node1@{ icon: "mdi:api", form: "rounded", label: "Node API replica 1", pos: "b", h: 56 }
            node2@{ icon: "mdi:api", form: "rounded", label: "Node API replica 2", pos: "b", h: 56 }
            bus@{ icon: "mdi:message-processing-outline", form: "rounded", label: "Service Bus work queue", pos: "b", h: 56 }
            jobs@{ icon: "mdi:cog-sync-outline", form: "rounded", label: "Container Apps background jobs", pos: "b", h: 56 }
            node1 --> service_access(("Authorised<br/>service access"))
            node2 --> service_access
            node1 --> bus
            node2 --> bus
            bus --> jobs
            jobs --> service_access
        end

        subgraph managed["Managed data, AI, Security, and Monitoring"]
            direction TB
            subgraph data_services["Permanent data, Cache, and Files"]
                direction LR
                postgres@{ icon: "mdi:database", form: "rounded", label: "PostgreSQL primary", pos: "b", h: 56 }
                redis@{ icon: "mdi:flash", form: "rounded", label: "Redis cache", pos: "b", h: 56 }
                blob@{ icon: "mdi:folder-multiple-outline", form: "rounded", label: "Blob files and evidence", pos: "b", h: 56 }
            end
            subgraph supporting_services["AI, Credentials, and Operations"]
                direction LR
                foundry@{ icon: "mdi:robot-outline", form: "rounded", label: "Microsoft Foundry AI", pos: "b", h: 56 }
                vault@{ icon: "mdi:key-variant", form: "rounded", label: "Key Vault", pos: "b", h: 56 }
                monitor@{ icon: "mdi:chart-line", form: "rounded", label: "Azure monitoring", pos: "b", h: 56 }
            end
        end

        ingress --> node1
        ingress --> node2
        service_access --> postgres
        service_access --> redis
        service_access --> blob
        service_access --> foundry
        service_access --> vault
        service_access --> monitor
    end

    subgraph connected["Connected Services"]
        direction LR
        erp@{ icon: "mdi:office-building-cog-outline", form: "rounded", label: "Tenant ERP", pos: "b", h: 56 }
        speech@{ icon: "mdi:microphone-message", form: "rounded", label: "Speechmatics — Live and Batch Transcription", pos: "b", h: 56 }
    end

    subgraph recovery["Azure Recovery Region"]
        direction TB

        subgraph recovery_entry["Prepared private application entry"]
            direction LR
            recovery_tunnel1@{ icon: "mdi:vpn", form: "rounded", label: "Recovery Tunnel definition 1", pos: "b", h: 56 }
            recovery_tunnel2@{ icon: "mdi:vpn", form: "rounded", label: "Recovery Tunnel definition 2", pos: "b", h: 56 }
            recovery_ingress@{ icon: "mdi:server-network", form: "rounded", label: "Recovery internal ingress", pos: "b", h: 56 }
            recovery_node1@{ icon: "mdi:server", form: "rounded", label: "Recovery Node definition 1", pos: "b", h: 56 }
            recovery_node2@{ icon: "mdi:server", form: "rounded", label: "Recovery Node definition 2", pos: "b", h: 56 }
            recovery_tunnel1 --> recovery_ingress
            recovery_tunnel2 --> recovery_ingress
            recovery_ingress --> recovery_node1
            recovery_ingress --> recovery_node2
        end

        subgraph recovery_data["Recovery Data Copies"]
            direction LR
            postgres_replica@{ icon: "mdi:database-clock-outline", form: "rounded", label: "PostgreSQL Recovery Replica", pos: "b", h: 56 }
            blob_copy@{ icon: "mdi:content-copy", form: "rounded", label: "Blob geographic copy", pos: "b", h: 56 }
        end

        recovery_node1 --> postgres_replica
        recovery_node2 --> postgres_replica
        recovery_node1 --> blob_copy
        recovery_node2 --> blob_copy
    end

    web --> tunnel1
    web --> tunnel2
    entra -.->|Signed-in user identity| node1
    entra -.-> node2
    erp --> jobs
    service_access --> speech
    postgres -.->|Continuous replication| postgres_replica
    blob -.->|Geographic copy| blob_copy
    edge -.->|Regional failover| recovery_tunnel1
    edge -.-> recovery_tunnel2

    classDef edgeService fill:#e9f3ff,stroke:#2463a8,color:#10253f,stroke-width:1.5px;
    classDef compute fill:#eaf8ef,stroke:#2f7d4a,color:#12351f,stroke-width:1.5px;
    classDef data fill:#fff3dc,stroke:#a96800,color:#402800,stroke-width:1.5px;
    classDef external fill:#f2ecff,stroke:#7251b5,color:#28184d,stroke-width:1.5px;
    classDef recoveryService fill:#f8eeee,stroke:#9a4b4b,color:#421d1d,stroke-width:1.5px;
    classDef junction fill:#ffffff,stroke:#5c6773,color:#20262d,stroke-width:1.5px;

    class browser,edge,web,entra edgeService;
    class tunnel1,tunnel2,ingress,node1,node2,bus,jobs compute;
    class postgres,redis,blob data;
    class foundry,vault,monitor,erp,speech external;
    class recovery_tunnel1,recovery_tunnel2,recovery_ingress,recovery_node1,recovery_node2,postgres_replica,blob_copy recoveryService;
    class service_access junction;

1. Frontend and edge protection. Customers reach the Next.js frontend through Cloudflare. Its content-delivery network (CDN) keeps common website files near users. Its web application firewall (WAF) filters malicious requests, and distributed denial-of-service (DDoS) protection absorbs traffic floods. The BFF prepares browser-facing requests without exposing private Azure addresses.
2. Sign-in and permissions. Microsoft Entra External ID signs users in through their organisation's identity provider. After sign-in, Node still checks the user's tenant and role before returning data.
3. Node.js backend. Normal requests cross either of two Cloudflare Tunnel connectors to the internal Container Apps entrance. A Tunnel connector creates an encrypted outbound connection from Azure to Cloudflare, so Node does not need a public Azure address. Container Apps distributes requests between two running Node replicas, which are separate copies of the same backend. If one stops, the other can continue. Azure Front Door and Cloudflare Load Balancing are therefore not included.
4. Speechmatics. For a live interaction, Node creates a short-lived, single-use ticket, keeps the Speechmatics credential private, and relays audio over a protected WebSocket connection. A WebSocket keeps a two-way connection open while the person speaks. Partial and final transcript text returns to the user; raw live audio is not stored. For a recorded voice note, Blob Storage holds the file and a background job submits it for batch transcription. Completed transcripts can become editable Process Intelligence drafts.
5. Data, cache, files, and work queue. PostgreSQL holds permanent records. Redis keeps temporary copies of frequently requested results but is never the only copy. Blob Storage holds documents, voice notes, and saved evidence. Service Bus holds small work instructions rather than business records.
6. Background processing. Container Apps Jobs imports read-only ERP data, processes documents and voice notes, and performs scheduled tenant analyses.
7. AI. Microsoft Foundry supplies the AI models. Models receive only the tenant information required for a task and do not receive unrestricted database access.
8. Credentials. Key Vault protects credentials. A managed identity allows an Azure service to authenticate without storing an application password.
9. Monitoring. Azure monitoring records health, failures, response times, and job status without recording business data, access tokens, audio, or transcripts.
10. Production disaster recovery. Initial Production restores PostgreSQL from a geographic backup. Standard Operations and Scaled Operations also maintain a continuously updated PostgreSQL recovery replica and inactive recovery Node and Tunnel definitions. Blob Storage keeps a geographic copy in every case. Development and staging use backups only.

Services included in the estimate

Explicitly excluded are Azure Front Door, API Management, AKS, Azure Document Intelligence, Data Factory, Logic Apps, Fabric, Power BI, AI Search, premium Service Bus, paid Defender plans, SMS authentication, Cloudflare Load Balancing, and production-style disaster recovery for development or staging.

3. How the supporting services work

Application data and cache

PostgreSQL is the application's system of record, meaning it holds the official permanent copy of tenant records, permissions, job status, evidence details, and audit history.

A vCPU is a share of a cloud server's processing power. Burstable compute can temporarily use more capacity; general-purpose compute provides steadier capacity. B2ms, D2ds v5, and D4ds v5 are Microsoft billing size names. D8 is a future scale-up trigger and is not included. A second database in another availability zone within the primary region is also not included initially.

Azure Managed Redis Balanced B0 is proposed from Initial Production onward: one non-high-availability cache with about 1 GB provisioned and 0.8 GB usable. It may hold tenant-scoped dashboards, reference data, repeatable calculations, and temporary session controls. PostgreSQL remains the permanent copy. A Redis failure should make responses slower rather than stop the application or lose records. High availability can be enabled later at the same endpoint, but it raises cost and may briefly clear or interrupt the cache.

Service Bus Basic is a managed work queue. Node places small instructions such as “process this document” on the queue; background jobs perform the work, while PostgreSQL and Blob Storage retain the real data.

AI processing

Microsoft Foundry provides models for assistant answers, process-map drafts, document interpretation, opportunity drafts, explanations, recommendations, and automatic tenant analyses. Node and background jobs provide only the information required for the current tenant and task. Models use typed, read-only application tools rather than unrestricted SQL.

An input token is a small unit of text sent to a model; an output token is text produced by it. The planning mix is 80% gpt-5.6-luna and 20% gpt-5.4-mini using Microsoft Foundry Global Standard capacity. Current public model rates produce a weighted rate of $0.31 per million input tokens and $1.86 per million output tokens.

Per active user per target month, assume 50 assistant questions, two average model steps per question and three maximum, 10 process-map generations with a 15% retry rate, and 100 other drafts, summaries, explanations, or recommendations. Add 100 automatic analyses per tenant.

Before document-page calls, this produces 4,330/42,800/106,750 model calls per month for Initial Production/Standard Operations/Scaled Operations. Including document pages and the 15% nonproduction allowance, planned monthly AI cost is approximately $16/$172/$722. Every result remains an editable draft until a user accepts it.

Speech and transcription

Real-time transcription converts speech to text while a person is speaking. Batch transcription converts an already recorded file after upload.

Speechmatics usage is 20/300/2,000 hours per month for Initial Production/Standard Operations/Scaled Operations, split 60% Batch Melia 1 at $0.129/hour and 40% Real-time Standard at $0.24/hour. Initial Production therefore includes 12 recorded and 8 live hours. The Pro plan provides 50 concurrent real-time sessions.

Speechmatics provides a one-time $100 account credit but no recurring free allowance. The estimate applies its 20% discount only to usage above 500 monthly hours for each transcription type. It does not assume the optional 33% model-training discount. After adding 15% nonproduction usage, monthly Speechmatics cost is approximately $4/$60/$356.

Raw live audio is not stored. Live transcript text remains for 90 days unless saved as evidence. Recorded voice notes follow the evidence rules below. Batch audio sent to Speechmatics is assumed to be deleted by the provider within seven days.

Evidence storage

Azure Blob Storage holds documents, voice notes, and evidence attachments. Hot storage is for recently used files and costs more to retain but less to retrieve. Cool storage costs less to retain when files are opened less often.

Files remain Hot for 30 days and then move to Cool, producing a planning mix of 20% Hot and 80% Cool. Ordinary files remain for 90 days; the estimated 10% selected as evidence remains for 36 months. Versioning preserves earlier versions, while soft delete allows a deleted file to be restored for 30 days. The estimate adds 10% storage for these protections.

Geo-redundant storage (GRS) keeps another copy in a second Azure region. Development and staging use sanitized data rather than copied customer data.

Monitoring and operations

Monitoring records application health, request times, and background-job results. It retains every error, security event, slow request, and failed job, while sampling routine successes to control cost.

Development and staging logs remain for 30 days; production logs remain for 90 days. Availability checks run every five minutes from one location for Initial Production, two for Standard Operations, and three for Scaled Operations. Logs must not contain business records, secrets, access tokens, audio, or transcripts.

Security and tenant separation

Microsoft Entra External ID performs enterprise sign-in. The customer's identity provider enforces multi-factor authentication, and email one-time codes add another check for sensitive administration. SMS authentication is not included.

Every business record includes a tenant identifier. Node verifies the signed-in user's tenant and role. PostgreSQL then applies row-level security, meaning database rules prevent one tenant's query from returning another tenant's rows. PostgreSQL uses private virtual-network access. Redis uses a private endpoint and private DNS. Blob Storage and Key Vault use restricted network access, encrypted connections, managed identities, and role-based permissions.

Disaster recovery

Disaster recovery restores production after a serious failure affects the primary Azure region. Backups recover deleted or damaged data; a recovery replica and prepared application definitions reduce the time required to restart elsewhere.

The recovery point objective (RPO) is the maximum expected data loss. The recovery time objective (RTO) is the target time for making the service usable again.

For a Standard Operations or Scaled Operations regional failure, the team promotes PostgreSQL, activates Blob recovery if required, starts two recovery Node instances and two recovery Tunnel connectors, and routes Cloudflare traffic to the recovery region. Redis is rebuilt because it contains only temporary copies. Unfinished work is reconstructed from PostgreSQL job records.

Development and staging use backups only. Run a backup-restoration test every quarter and rehearse the complete production regional-recovery procedure once each year.

4. Cost Breakdown

The estimate covers the proposed Azure, Cloudflare, and Speechmatics services for development, staging, and production. Rates use public USD pay-as-you-go inputs, provisional East US/East US 2 pricing, and monthly Cloudflare billing. Calculations retain cents; tables round to whole dollars.

Target monthly cost build-up

A target month is a fully operating month at the workload shown for each scenario. The amounts below are gross costs before credits, so every service can be followed into the monthly total.

Mostly fixed means capacity is billed to remain ready even when usage is low. Usage-driven means the cost grows with activity. Mixed means the service has both ready capacity and consumption charges. Entra remains within the modelled free monthly active-user allowance. Individual service rows are rounded to whole dollars, while subtotals use the underlying cent values; this is why the displayed Scaled Operations Azure lines add to $2,404 but the calculated Azure subtotal rounds to $2,405.

How the one-year amounts are calculated

• Fixed capacity is charged for all 12 months.
• Launch-year usage grows linearly from near zero to target and is calculated at each monthly midpoint. Steady-state usage remains at target for all 12 months.
• The 15% development/staging allowance is added before free allowances or discounts.
• Speechmatics discounts and Azure's first 100 GB per month of free internet transfer are recalculated at every monthly midpoint.
• The 30% sensitivity case increases variable inputs before thresholds and credits are recalculated.
• Microsoft Azure credit applied is the lower of $5,000 or the eligible annual Azure charge. Speechmatics credit applied is the lower of $100 or the annual Speechmatics charge.

The calculation follows two steps: gross annual cost = Azure + Cloudflare + Speechmatics, then net payable = gross annual cost − applied Azure credit − applied Speechmatics credit. This estimate assumes the full $5,000 Microsoft ISV Success Azure sponsorship credit is active and applies Speechmatics' one-time $100 account credit. A credit reduces only that provider's charges; unused credit is not cash and cannot reduce Cloudflare charges.

Annual cost bridge

This table shows how the service charges and provider-specific credits produce the final amount payable. Parentheses indicate a credit being subtracted.

For Initial Production launch year, the calculation is $3,554 Azure + $360 Cloudflare + $24 Speechmatics − $3,554 Azure credit − $24 Speechmatics credit = $360 payable. Initial Production has the same $360 net result in steady state because its Azure and Speechmatics charges remain below their credit limits. The remaining $360 is Cloudflare at $30 per month for 12 months.

Higher-usage sensitivity

The Initial Production sensitivity remains $360 because the increased Azure and Speechmatics usage is still fully covered by the assumed credits. Each row and year basis is an independent alternative for planning; the same annual Azure credit and one-time Speechmatics credit are shown in each alternative only to compare outcomes and cannot be claimed repeatedly for simultaneous cases.

Microsoft ISV Success benefits included in the estimate

5. Assumptions, exclusions, review triggers, and sources

• No reservations, savings plans, negotiated prices, taxes, or currency conversion are included. Review commitments only after three to six months of stable production measurements.
• Microsoft Marketplace integration, fees, and revenue are outside this assessment; no listing status is assumed.
• Labour, support staffing, compliance certification, ERP licences and API fees, adapter implementation, and sales costs are excluded.
• Re-price for a confirmed region or data-residency requirement; provider or model price changes; more than one ERP per tenant; retention or workload movement above 20%; Redis high availability; PostgreSQL zone high availability or D8; Cloudflare Business; or Speechmatics Enterprise.
• Reconcile the estimate with invoices and measured application, database, AI, document, speech, storage, data-transfer, and monitoring usage after launch.

Official source register

Sources were retrieved on 28 August 2026. Azure line items use the Retail Prices API where it exposes a meter; provider pages establish public prices and architecture assumptions. Region, subscription, quota, model availability, and measured usage can change the actual bill.

• Microsoft compute: Azure Retail Prices API, Container Apps pricing, Container Apps networking, and Container Apps Jobs.
• Microsoft data: PostgreSQL Flexible Server pricing, business continuity, Azure Managed Redis pricing, and Blob Storage pricing.
• Microsoft platform: Service Bus pricing, Entra External ID pricing, Key Vault pricing, Azure Monitor pricing, and Container Registry pricing.
• Microsoft AI and programme benefits: Microsoft Foundry model availability, ISV Success, and ISV benefit quantities.
• OpenAI model prices: gpt-5.6-luna and gpt-5.4-mini, used with Microsoft Foundry availability and subject to confirmation against the Azure subscription before deployment.
• Cloudflare: plans, Workers pricing, Tunnel availability, and DDoS protection.
• Speechmatics: Speech API pricing, including Batch Melia 1, Real-time Standard, the account credit, and volume discounts.