Skip to main content

Networking and connectivity

A Builder App serves its active static and web outputs through the app's public URL. Networking to dependencies and authorization to those dependencies are separate requirements.

Public ingress and component routes​

After deployment succeeds, read properties.runtime.url or use the app link in Portal. Use the service-provided URL; custom-domain provisioning is not a supported Builder customer workflow in this preview. Protect visitor access with deployed-app authentication.

builder.yaml maps a component's public path to its output. At most one static output and one public web output can be deployed. More-specific public prefixes take precedence over /.

For a web component:

components:
  - name: api
    role: web
    platform: nodejs
    path: /api
    run:
      start: node server.mjs
      port: 8080
      healthCheckPath: /api/health

The application must listen on a non-loopback interface at its configured port and implement /api/health. Do not assume the component mount is stripped before the app sees the request. run.port is the web process's listening port, not an additional customer ingress port or a public TCP-service mapping. See the manifest reference for health and route semantics.

Outbound access​

Application code can call a reachable Azure or external endpoint using its service SDK or HTTP client. Configure the endpoint and required settings using variables. The app can authenticate with its managed identity. The destination still controls firewall rules, authentication, and data-access permissions.

Verify DNS resolution, TLS, connectivity, and authorization from the deployed app. A successful call from your laptop does not prove the preview target can reach the same endpoint. Builder does not expose a customer-configurable stable outbound IP, egress webhook, or egress policy in the documented app contract. Do not build a dependency allowlist around an assumed address or disable a destination firewall just to make a sample work.

VNet integration and private endpoints​

Customer-selected VNet/subnet integration and a private endpoint for the Builder App are not supported workflows in this preview.

A private endpoint on Cosmos DB, Key Vault, or Storage restricts how that dependency can be reached; it does not connect Builder to the dependency's network. Managed identity grants credentials, not routing, private DNS, or firewall access. If the dependency is private-only, this preview does not provide a supported Builder connection recipe. Keep its restrictions intact and confirm an appropriate supported hosting/network arrangement with your preview owner.

Browser and server connections​

For a static frontend, outbound API calls originate in the user's browser. The API must permit the intended browser origin and enforce its own authentication/authorization. For server-side calls, credentials stay in the web process; never place them in frontend build output. Builder has no documented app-level CORS settings surface; configure CORS in application code where needed.

Use connecting to services for the endpoint/identity/permissions checklist, including its Cosmos DB example.

Last updated on