Microsoft Foundry: Is Deploy as Web App Enough, or Do You Need a Backend Proxy?

Teams still celebrate when the container listens on the right port. For Foundry-backed agent webapps, that is the easy half. The hard half is who the app runs as, how OBO flows, and how egress reaches Foundry, Search, and storage without turning the VNet story into folklore.

Deploy the pattern as identity and networking first. Hostname and Node version are table stakes.

Figure 1. Identity and egress first. A Foundry webapp is an identity and egress design that happens to run a container. Hostname celebration is not staging proof.

Context and constraint

A common pattern with container App Service fronts to Foundry: demos work on a laptop and staging fails on DNS and identity. Prompts were fine. The managed identity and private DNS were not.

Reuse ACR, App Insights, and Entra app registrations instead of inventing a second identity plane. Regional VNet integration is for egress. Public ingress is a separate product decision. On-behalf-of only works if the app runs as the right user-assigned identity with the right API permissions. Private DNS and subnet planning beat "it works on my laptop" confidence.

Figure 2 is the Learn surface for regional VNet integration. Integration changes name resolution and outbound paths more than hostnames do.

Figure 2. Regional VNet integration gives the app a path out to private endpoints. It does not by itself decide whether users reach the app from the public internet. Source: Microsoft Learn: App Service VNet integration.

Design

1. Reuse the identity plane

One Entra app registration story for the API, one user-assigned managed identity for Azure resources, consistent App Insights. Do not create parallel app registrations per environment without a map. Reuse ACR so image provenance stays boring. New identity objects need owners and rotation stories.

2. Separate ingress product decisions from egress mechanics

VNet integration gives the app a path out to private endpoints. It does not by itself decide whether users reach the app from the public internet, Front Door, or private access. Write those as two sections in the design. Mixing them produces diagrams nobody can implement. Figure 3 is the split.

Figure 3. Ingress posture versus egress mechanics. Public ingress plus private egress is a valid stage choice. One cloud labeled private is not a design.

3. OBO requires the right runtime identity and permissions

Secretless OBO flows fail in confusing ways when the app identity lacks the API permissions or when the token audience is wrong. Validate identity and consent before you tune prompts. "Model is slow" is a common mislabel for auth failures.

4. Plan subnets and private DNS on purpose

Foundry, Cognitive Search, and storage private endpoints need DNS that the App Service integration subnet actually uses. Missing private DNS zones show up as intermittent platform errors that look like SDK bugs. Checklist name resolution from the app outward.

5. Deployment checklist: identity and DNS before prompt quality

Gate releases on: identity assigned, role assignments present, private DNS resolving, egress to dependencies verified, App Insights receiving. Prompt evals come after the plane is honest. Otherwise you iterate on wording while the network drops calls. Figure 4 is the order of proof.

Figure 4. Order of proof. DNS, roles, and OBO before prompt suites. Reverse that order and you get beautiful evals on a plane that still cannot reach production dependencies.

6. Containers are portable; the plane is not

The same image can run in a lab without private endpoints. That does not prove MVP readiness. Environment parity for identity and networking matters more than matching Node patch levels.

Reuse without freezing the wrong thing

Reusing ACR and App Insights does not mean every stage shares the same secrets or the same private endpoint set. Reuse the pattern and the resource types. Isolate the instances. Write the matrix: which registrations, which identities, which DNS zones per stage. The matrix is dull. The outage from a missing row is not.

Order of proof in staging

Prove DNS resolution to private endpoints from the app. Prove managed identity role assignments on Foundry, Search, and storage. Prove OBO with a real user path. Only then run prompt suites. Reversing that order produces beautiful eval spreadsheets on a plane that still cannot reach the dependency graph in production. Identity and egress are the release train; prompts ride in the passenger car.

If staging still uses public Foundry endpoints "temporarily," label that debt in the ADR with an owner. Temporary networking exceptions have a habit of surviving until the first security review.

Keep a single networking diagram per stage in the repo next to the checklist so onboarding does not depend on a whiteboard photo.

Failure modes

Hostname obsession. TLS and DNS for the hostname done; egress to Foundry ignored.

Second identity plane. Duplicate app registrations and conflicting redirect URIs.

OBO with the wrong MI. Tokens mint; resource calls 401/403.

"Works on laptop" as staging proof. Public Foundry endpoints hide private DNS gaps.

Prompt tuning during outages. Wasted cycles on the wrong layer.

Public ingress assumed forever. Product later wants private; redesign is expensive.

What to copy / what not to copy

Copy

• Container App Service with regional VNet integration for private egress.
• User-assigned managed identity plus named Entra app registrations; no duplicate planes without a map.
• Secretless OBO with verified API permissions.
• Private endpoints and private DNS for Foundry, Search, and storage as required for the stage.
• Ingress posture (public vs fronted vs private) decided explicitly per stage.
• Release checklist validates identity and DNS before prompt/eval work.

Do not copy blindly

User-assigned identities and private endpoints cost setup time and platform skill. They remove secret sprawl and public dependency exposure. Strict checklists slow the first deploy and speed every incident after. Reusing Entra apps across stages needs careful redirect and audience hygiene; duplication feels easier until consent screens multiply. VNet integration constrains scale choices; document them instead of discovering them in a fire drill.

Primary references: App Service VNet integration, managed identities, and Microsoft Foundry networking guidance on Microsoft Learn.

Deploy identity and egress as the product. Then tune the Node host. The demo order is the opposite; the production order is not.