Foundry webapps deploy as identity and egress, not as Node hostnames

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. Foundry webapps deploy as identity and egress. VNet integration changes name resolution and outbound paths more than hostnames do. Source: Microsoft Learn: App Service VNet integration.

I learned this shipping container App Service fronts to Foundry where demos worked on a laptop and staging failed on DNS and identity. Prompts were fine. The managed identity and private DNS were not.

The core idea

A Foundry webapp is an identity and egress design that happens to run a container.

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.

A model that stays explainable

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 site from the public internet, Front Door, or private access. Write those as two sections in the design. Mixing them produces diagrams nobody can implement.

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.

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.

Failure modes I design against

Hostname obsession. TLS and DNS for the site 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.

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.

Trade-offs

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.

What I would put on an ADR

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

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

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 compliance review.

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

Closing

Nobody thanks you for a green container that cannot reach Foundry privately or mint the right OBO token.

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