How On-Tenant Works

Corral deploys entirely into your own Azure tenant using Azure Managed Applications — a specific Azure capability that lets a publisher deploy and maintain resources inside a customer’s subscription.

This page explains the mechanism, why it matters, and how it differs from other deployment models.

Azure Managed Applications

When you click “Deploy” on the Azure Marketplace, Azure creates a managed resource group in your subscription. This is a container for all the resources Corral provisions. You can see everything inside it. Corral can maintain it. The boundaries of who can do what are configurable.

This is not a proprietary mechanism — it’s a standard Azure capability used by many marketplace publishers. What’s distinctive is that Corral uses it to deploy a complete AI platform, not just a single service or connector.

Why This Capability Matters

Azure Managed Applications provide three things that no other cloud offers in combination:

1. Publisher maintenance access — Corral can push updates, manage configuration, and operate the deployment without the customer doing manual upgrades
2. Customer ownership — all resources live in the customer’s subscription, billed to the customer, visible in their Azure portal
3. Configurable access boundaries — the customer controls how much access the publisher has, from full standing access to just-in-time approval to no access at all

Neither AWS nor GCP have a direct equivalent. This is why Azure is Corral’s starting platform.

What Makes This Different

vs. SaaS

In a SaaS model, your data lives in the vendor’s infrastructure. You trust the vendor not to access it, based on their policies and certifications. Data residency depends on where the vendor chooses to host.

With Corral, your data lives in Azure resources you own. Corral doesn’t host your data — the architecture doesn’t include a data path from your tenant to ours. Data residency is wherever you put your Azure subscription. You verify compliance yourself by inspecting your own resources.

vs. Self-Hosted / On-Prem

In a self-hosted model, you install the software and take full responsibility for updates, security patches, database migrations, and infrastructure management.

With Corral, you get the data-residency benefits of self-hosted with the maintenance benefits of SaaS. Corral pushes updates. You don’t manage container deployments or database migrations. The software stays current without your ops team being responsible for it.

Billing

You pay two things, separately:

Platform subscription — Corral’s fee for the software and ongoing maintenance. This is a line item on your Azure Marketplace bill, configured via Azure Partner Center.

Azure resource consumption — The compute, storage, database, AI services, and networking that Corral deploys. These are standard Azure resources on your subscription. Azure bills you directly, just like any other resource you own.

Both charges can count against your existing MACC (Microsoft Azure Consumption Commitment) spend. This means Corral draws from your committed cloud budget, not a new line item.

The platform subscription replaces the $500K+ SI engagement or internal build cost. The Azure consumption is infrastructure you’d pay for regardless of how you built your AI platform.

How Corral Maintains Your Deployment

Corral does not maintain standing interactive access to your environment. There are no SSH sessions, no portal logins for routine operations.

Maintenance is performed through GitHub Actions workflows that authenticate to your tenant using a federated identity credential on the managed identity. This means:

• Every maintenance action is a tracked workflow run — code-driven and auditable
• No human logs into your environment for routine operations
• The federated credential is scoped to a specific GitHub repository and environment

What Corral Can Do (via the maintenance mechanism)

• Deploy and update application containers
• Update infrastructure configuration
• Read deployment metadata from Key Vault
• Push container images that your Container Apps pull

What Corral Cannot Do (by architecture)

• Access your SQL database interactively at runtime
• Access your broader Azure tenant (scoped to the managed resource group)
• Read your data through normal operations — there is no runtime phone-home, no telemetry sent back to Corral’s infrastructure

Transparency Note

The managed identity has Resource Group Owner on the managed resource group. This is the standard pattern for Azure Managed Applications — the publisher needs sufficient permissions to maintain the deployment. This role could theoretically be used to retrieve database connection strings and add firewall exceptions within that resource group. It cannot access anything outside the managed resource group.

Mitigations: your Azure Activity Log captures every action taken against resources in the managed resource group. All publisher operations are visible and auditable by your team at all times. Azure Policy alerts for unexpected access patterns are planned as an out-of-box configuration.

Communication Between Your Tenant and Corral

Publisher Access Tiers

Azure Managed Applications support three publisher access levels. These are configurable:

For production customer deployments, just-in-time access is the recommended configuration — Corral requests access when maintenance is needed, and you approve with a defined time window.