Skip to main content

Sample applications

Each App Service Builder sample has its own Azure-Samples repository. Fork the repository to your GitHub account to adapt one build shape at a time. You can also start from a Portal template to create the fork during app creation. If you already have a fork, keep it and choose Use my repository.

Verify your preview environment

Confirm access, location, and runtime support with your preview contact before deploying.

At a glance​

  • Each sample has a root-level builder.yaml in its own repository.
  • Fork the selected repository and use safe configuration values.
  • Wait for deployment success and verify the app URL.
  • Follow the repository README for local checks and customization.

Choose a sample​

For a first deployment without browsing the catalog, start with Portal or Builder CLI. Both quickstarts recommend the minimal Node.js HTTP sample and let you keep an alternative you have already selected.

To choose another sample, start with the app shape, then choose the source language below. Use Node.js, Python, .NET, PHP, or static HTML/Vite tutorials for runtime-specific settings and verification. Each tutorial includes Portal and Builder CLI deployment steps and cleanup. Static samples serve browser assets without a compute process; web samples run an HTTP process. TypeScript in the Vite sample produces static browser assets, not a separately supported compute platform.

The JavaScript web samples include a stateless HTTP MCP server and a bounded model-backed agent API. See hosting an MCP server and hosting an AI agent API for their protocol, dependency, and security requirements. These are applications you deploy, not Builder-managed MCP or agent services.

8 of 8 samples

Static sites

Publish browser-ready files or build frontend assets. No server process is deployed.

  • Static HTML

    • HTML/CSS

    Browser-ready HTML served directly from public, without a build or compute process.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

  • Vite TypeScript

    • TypeScript

    A Vite and TypeScript app built into static dist assets.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

Web apps and HTTP APIs

Run a request-driven application with a public endpoint and an explicit health check.

  • Node.js HTTP

    • JavaScript

    A dependency-free Node.js HTTP server with a public greeting and health endpoint.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

  • Python HTTP

    • Python

    A standard-library Python HTTP server with a public greeting and health endpoint.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

  • ASP.NET HTTP

    • C#

    A minimal .NET 10 HTTP app with a public greeting and health endpoint.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

  • PHP HTTP

    • PHP

    A PHP 8.5 app using default nginx/PHP-FPM startup, with a public greeting and health endpoint.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

  • HTTP MCP server

    • JavaScript

    A stateless JSON-response MCP endpoint with a bounded read-only text tool.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

  • AI assistant HTTP API

    • JavaScript

    A bounded, single-turn assistant using an explicitly configured external model service.

    Confirm access, location, and runtime support before deploying.

    View repository on GitHub

Repository links open GitHub. For PHP, keep default nginx/PHP-FPM startup with no run.start; follow the PHP tutorial. Next.js has no supported sample here and is not offered as runnable source.

Deploy your copy​

  1. Review Private Preview guidance: development/test only; do not deploy production workloads. Obtain your preview environment details and, for CLI use, install the published CLI package.
  2. Open the selected Azure-Samples repository and choose Fork to create your own repository.
  3. Review its README, runtime requirements, and root builder.yaml. Clone the fork if you want to make local changes or deploy with Builder CLI. Portal can deploy the committed fork without local tools.
  4. If you change the application, commit and push to the intended branch in your fork.
  5. Authorize GitHub source access to your fork, not the upstream sample repository.

Each repository contains one sample, so use its repository root as the app source root (rootDirectory: "." in ARM). Keep builder.yaml at that root. If you later move your app into a larger repository, configure its source root explicitly.

Keep the fork, branch, and root builder.yaml you prepared above. Builder deploys committed GitHub source, not uncommitted local files.

Open the App Service Builder Portal. Your Azure account needs permission to create and deploy Microsoft.Web/builderApps resources. Creating a resource group also requires permission to create groups in the selected subscription.

  1. Sign in to the Portal with the Microsoft account authorized for your subscription.
  2. Select the subscription and choose Create.
  3. In Connect GitHub, sign in to GitHub and authorize the OAuth App. Keep Use my repository selected to deploy the fork you prepared above. Choose the account or organization that owns your fork, then select that repository and branch. Use Change account if you need a different GitHub account, or Refresh access after changing repository permissions. Select Next.
  4. In Choose approach, confirm the selected repository and branch. Keep Let Builder handle it selected. The App Service Builder GitHub App needs access to this repository to read your code, build it, and deploy your app. Signing in to GitHub alone does not grant this access. If prompted, select Install GitHub App and grant access to your selected repository, or add it to an existing installation. Close the GitHub window to refresh access, or select Refresh access after approval. Select Next when Builder is connected and GitHub App access confirmed are shown.
  5. In App details, enter an app name and select the subscription, resource group, and offered location. To create a resource group, select Create new, enter its name, and choose Resource group region. Select Add. The group appears as (new) and is created when you submit. Its region stores the resource group's metadata and does not change the app's region. Select Next.
  6. On Review and create, confirm the app, repository, branch, subscription, resource group, and app region. Select Create and deploy.
  7. Open the app's Deployments page and wait for the deployment to succeed. In Versions, inspect the source revision, component results, and build logs. Select Deploying to open an in-progress deployment's steps and logs. On Overview, use Browse to open the app URL.

Already prepared a fork? Keep Use my repository selected so you deploy that source, not a second copy. To start with a new sample instead, follow Create from a Portal template. Use GitHub Actions is marked Coming soon; use the Builder-managed approach for this preview.

If group creation fails, app creation does not start. If the group was created before a later failure, it remains in Azure; cancelling does not delete it. Check the existing group and app before retrying, and inspect a group's contents before deleting it separately.

See GitHub authorization requirements for organization approvals and SSO. If app creation succeeds but deployment cannot start, read the error and retry deployment on the existing app rather than creating a duplicate. For “Source revision does not contain builder.yaml”, push the missing manifest before retrying.

For API automation, use the ARM API deployment guide with this same fork, branch, and source root ".". ARM and Bicep infrastructure templates provision the resource; separately authorize and connect this source, then deploy it through CLI or ARM.

Verify the hosted sample​

After deployment succeeds, open the returned app URL and perform the response checks from the selected repository's README. Check the active version and source revision as well as the endpoint. For MCP or model-backed samples, verify a real authenticated protocol or model request; process health alone does not establish that the integration works.

Clean up resources​

Delete only the test app you created when you no longer need it. App deletion does not remove your GitHub repository, resource group, or separately owned services and user-assigned identities.

Return to the app inventory and choose Delete from the test app's actions. Alternatively, open the app's Settings and select Delete under Danger zone. Confirm the selected app and follow deletion to completion. Deleting from Settings returns you to the home inventory after the deletion request is accepted.

Combine static and web outputs​

Builder can combine one static output and one public web output in an app. The current catalog contains focused static and web samples, not a combined full-stack sample. The manifest guide explains composition and build/output paths. Runtimes explains supported languages and framework limitations, and authentication adds visitor sign-in after the app is deployed.

Last updated on