Skip to main content

Deploy your first app with the Portal

In this quickstart, you deploy a small HTTP app from your GitHub fork with App Service Builder. Start with the recommended sample or keep another sample you have already chosen. Use the Portal to connect source, deploy, verify the running app, and delete the test app.

Prerequisites​

  • Private Preview access to the App Service Builder Portal. Use development/test workloads only; do not deploy production workloads.
  • An Azure account with permission to create and deploy Builder apps in your subscription and approved region.
  • A GitHub account that can fork the sample and authorize source access.
  • Confirmed Node.js 24 availability for the recommended sample, or confirmed support for your selected alternative.

You do not need Node.js, Git, or Builder CLI locally to deploy a committed GitHub fork with the Portal. See access and sign-in if your accounts or preview access are not set up.

Prepare your source​

The recommended starting point is the minimal Node.js HTTP sample. It includes application code and a root builder.yaml for Node.js 24, a listener on port 8080, and a /health deployment check.

Confirm your selected runtime and version are available for your preview location before starting. Local manifest validation and a successful build do not establish runtime availability; see target runtime availability.

Open the repository and choose Fork to create your own copy. Keep the sample files and root builder.yaml together. Use your fork's account, repository name, and branch in the steps below. Commit and push any changes; Builder deploys GitHub commits, not uncommitted local files.

Want a different sample? Choose another published sample or follow a language tutorial. Bringing your own code? Add a builder.yaml at your app's source root before deploying. It tells Builder how to build and start your app. The published samples already include this file. Use the manifest guide to create it yourself or with the Builder agent skill. Commit and push builder.yaml with your code. Keep your existing repository rather than replacing it with a sample; source roots explains apps in subdirectories.

Create and deploy the app​

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.

Verify the hosted app​

After deployment succeeds, open the app's returned runtime URL. For the recommended Node.js sample with its default greeting, the page shows App Service Builder / nodejs-web: Hello. Its /health endpoint returns HTTP 200 with body OK followed by a newline.

You can also check both endpoints from a terminal, using the returned URL without a trailing slash:

curl -i "<app-runtime-url>/"
curl -i "<app-runtime-url>/health"

Both requests should return HTTP 200 for the recommended sample. If you chose another sample or changed its behavior, use its README for the expected response and health path; PHP uses /health.php, for example. Check the active version and source revision as well as the response. A saved source connection, ready build, or accepted request is not a completed deployment.

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.

Related content​

Use language tutorials to understand runtime-specific build and startup settings. Use deployments to update the app after pushing a new commit. Use the CLI quickstart if you prefer the same journey from a terminal. See preview feedback guidance for the public issue tracker and safe-sharing requirements. For setup or deployment help, check support availability.

Last updated on