Skip to main content

Azure BYOC Deployment

This guide describes how the Viven Digital Twin platform is deployed within the customer's own Virtual Private Cloud (VPC) on Microsoft Azure. This deployment model is also known as Bring Your Own Cloud (BYOC).

Advantages of this setup:

  • Customer's data resides within their own cloud and never leaves it
  • Application logs are stored within the customer's cloud
  • Customer has full control over the deployment

Customers will need to provide a new and blank Azure subscription where Viven will deploy the complete Digital Twin stack. All data, including application logs, will be stored within the customer's cloud.

Need help?

At any point, reach out to your Viven representative or support@viven.ai.

Overview​

StepTask
Step 1Create a subscription for Digital Twin
Step 2Share access details with Viven
Step 3Configure your domain for Digital Twin

Step 1: Create a Subscription​

  1. Sign in to the Azure Portal

  2. Navigate to Subscriptions

    • In the search bar at the top, type Subscriptions
    • Click Subscriptions from the results

  3. Create the Subscription

    • Click the + Add or Create button at the top of the Subscriptions page

  4. Choose Subscription Type

    • Select the appropriate subscription offer type (Pay-As-You-Go, Enterprise Agreement, etc.)
    • This depends on your billing account type

  5. Review and Create

    • Review all settings
    • Click Create to provision the new subscription
note

No billing or charges will occur yet. Services will only be activated later during Viven's deployment.

Step 2: Share Access Details with Viven​

Grant the following role assignments at the subscription level:

  • Contributor access
  • User Access Administrator access (for assigning roles)

Assign these roles to:

  • The Viven infrastructure team
  • The Managed Identity (prod-dt)

Step 3: Configure Your Custom Domain​

warning

Complete this step only after the Viven team has provisioned the infrastructure.

This step enables you to set up and validate your domain for Digital Twin — for example digitaltwin.yourdomain.com — and a staging server at stage-digitaltwin.yourdomain.com, using Azure Front Door, AKS app origins exposed through Private Link Service (PLS), and the necessary DNS records.

See the Configuring Custom Domain (CNAME) section below for the detailed walkthrough.

Steps After Infrastructure Setup​

Congratulations! Once your Digital Twin infrastructure stack is live, your Viven representative will follow up with you on:

  1. Connector setup — Connect your Digital Twin system to enterprise data sources such as Google Workspace, Microsoft 365, Salesforce/Slack, Atlassian, and more.

  2. SSO (Single Sign-On) setup — Provide your Identity Provider (IdP) configuration: IdP entity ID, SSO URL endpoints, and X.509 certificates for verification.

  3. LLM setup — Digital Twin currently uses Azure OpenAI models. OpenAI does not train on any inputs or outputs from their products for business users.

  4. User limiting (if required) — Limiting access is best handled via SSO. The Admin Console also allows admins to restrict users directly.

Appendix​

Configuring Custom Domain (CNAME)​

This guide walks through validating your custom domain with Azure Front Door and AKS app origins exposed through Private Link Service (PLS), and configuring the required DNS records.

Example configuration for stage-digitaltwin.yourdomain.com pointing to:

  • Front Door endpoint: stage-digitaltwin-xyz.azurefd.net
  • AKS private origin: stage-digitaltwin-aks-origin (via Private Link Service)
Record TypeHost / NameValueTTL
TXT_dnsauth.stage-digitaltwin.yourdomain.comabcd1234-5678-90ef-ghij-klmnopqrstuv (Front Door validation token)3600
CNAMEstage-digitaltwin.yourdomain.comstage-digitaltwin-xyz.azurefd.net3600

Notes:

  • DNS propagation typically completes within a few hours
  • All TXT and CNAME records must remain in your DNS configuration permanently
  • Repeat these steps for each environment (staging, production) with their respective subdomains
  • Recommended subdomains:
    • Staging: stage-digitaltwin.yourdomain.com
    • Production: digitaltwin.yourdomain.com

The custom domain has already been added to your Front Door instance. Validate it by adding a TXT record.

  1. Navigate to the Azure Portal and open your Front Door resource (e.g. stage-digitaltwin-xyz)

  2. In the left navigation, click Domains

  3. Locate your custom domain — status will show Validation state: Pending

  4. Click the Pending status to view validation details. Azure will display the required TXT record:

    Name:  _dnsauth.stage-digitaltwin.yourdomain.com
    Type:  TXT
    Value: abcd1234-5678-90ef-ghij-klmnopqrstuv

  5. Add this TXT record in your DNS provider:

    • Host/Name: _dnsauth.stage-digitaltwin (some providers require the full FQDN)
    • Type: TXT
    • Value: The validation token provided by Azure
    • TTL: 3600

  6. Wait for DNS propagation and Azure validation (typically 15 minutes to 2 hours). The state will change from Pending to Approved.

Add a CNAME record to point your custom subdomain to the Front Door endpoint:

  1. In your DNS management console, create a new CNAME record:

    • Host/Name: stage-digitaltwin (or your subdomain prefix)
    • Type: CNAME
    • Value: Your Front Door endpoint URL (e.g. stage-digitaltwin-xyz.azurefd.net)
    • TTL: 3600
    stage-digitaltwin.yourdomain.com  →  stage-digitaltwin-xyz.azurefd.net
  1. Navigate to the Azure Portal and open your Front Door resource
  2. Under Origin groups, open the stage or production origin group
  3. Verify that the configured origin points to the AKS app origin exposed via Private Link Service
  4. Confirm the origin health state is Healthy after DNS propagation and approval
  5. Repeat verification for each environment (stage-digitaltwin and digitaltwin)

Services Deployed​

The Digital Twin platform comprises the following Azure services:

Azure ServicePurpose
Azure Front DoorSecurely distributes the application with low latency to users
Azure Kubernetes Service (AKS)Hosts the Digital Twin web application (stage and production), processor workers, and OpenSearch workloads
Azure Private Link Service (PLS)Exposes AKS app origins privately to Azure Front Door
Azure Virtual MachinesCompute instances and Airflow
Azure Synapse AnalyticsStores application and access logs
Azure SQL DatabaseStores user information and application configuration (managed SQL service)
Azure DNSManages domain records
Azure Managed RedisCaches results of expensive I/O calls and computations
Azure Cosmos DatabasePrimary datastore for processed data
Azure Container Registry (ACR)Stores container images for deployment
Azure Blob StorageStores raw ingested documents, builds, and other artifacts
Azure Active Directory (Azure AD)Creates and manages identities and access control
Azure Key VaultStores application secrets (API tokens, etc.)
Azure Service BusQueues tasks for background workers
Azure Event HubsStreams application logs to Synapse Analytics
Azure Stream Analytics JobPulls data from Event Hubs into Synapse Analytics
Azure MonitorCollects metrics and logs for monitoring and observability

Document Ingestion Architecture​

1. Scheduled Orchestration

An Airflow DAG runs every 30 minutes and queues an ingestion job for the Azure Container Apps Worker cluster for each source system (Outlook, SharePoint, Teams, etc.).

2. Azure Container Apps Worker Cluster Processing

The worker cluster processes each ingestion job in four stages:

StageDescription
Document IngestWorker calls external source systems via Connectors and pulls documents; raw files are stored in Azure Blob Storage
Document StoreDocument metadata is stored in Azure Cosmos Database
Document ProcessDocuments are enriched using Azure OpenAI Service; enriched data is stored in Azure Cosmos Database
Document IndexDocuments and their embeddings are indexed in OpenSearch for search and retrieval

Deployment and Monitoring Operations​

Deployment Updates​

Infrastructure provisioning is automated using Terraform scripts triggered from Viven's central account.

New service versions are built as Docker images and pushed to Elastic Container Registry (ECR) in Viven's central account. When a new version needs to be deployed in the customer's account, the following workflow runs:

  1. Viven triggers a new deployment by pushing a message to S3
  2. Customer Airflow polls the message and runs a deployment script that pulls the latest image from Viven's central ECR and deploys it to the customer's environment, then restarts the service
  3. On completion, a status message is posted back to Viven's central account to confirm success or failure and track the deployed version

To enable this, Viven will provision the customer's account with read-only access to Viven's central ECR.

Application Logs and Configuration Access​

Application logs are stored in Synapse Analytics and application configuration is stored in MySQL — both within the customer's account. Viven has built tooling to provide easy interfaces for accessing this data.

When troubleshooting issues, Viven may need to access logs and configuration information, or update configuration to enable new features. A dedicated user login is provisioned in the application to allow Viven's team to access these tools.