Skip to main content

Deploy a PHP app

In this tutorial, you deploy a PHP 8.5 sample using App Service Builder's built-in web server. Use Portal or Builder CLI, verify the running app, and delete the test app when finished.

Prerequisites​

  • Private Preview access, an authorized subscription, and an available region. Use development/test workloads only.
  • A GitHub account that can fork the sample and authorize source access.
  • Confirmed PHP 8.5 availability in your preview environment.
  • For optional local changes and checks: Git, PHP 8.5.x, and Composer 2.x. The optional local test runner also requires Python 3.10 or later; Python is not an app runtime dependency. You do not need these tools locally to deploy a committed fork with Portal.

Prepare your source​

Fork the PHP sample repository. For local changes, clone your fork:

git clone https://github.com/<your-github-account>/app-service-builder-php.git
cd app-service-builder-php

Follow its README for local checks. Keep builder.yaml, composer.json, composer.lock, index.php, and health.php at repository root. The sample has no third-party Composer packages. Commit and push changes to your selected branch before deploying.

Review build and startup settings​

Builder uses the sample's builder.yaml and its built-in nginx/PHP-FPM server. You do not need a custom startup command.

SettingSample value
Platformphp, version "8.5"
Source folderRepository root
Hosted startupDefault nginx/PHP-FPM; omit run.start
Served filesindex.php and health.php at the build output root, not under public/
Port and app pathPort 8080 and path /
Health check/health.php, returning HTTP 200

Keep the sample's default startup; do not use a PHP development server as hosted startup. If adapting it, keep index.php and health.php at the build output root. See PHP runtime notes for Composer, custom builds, and document-root details.

Create and deploy the app​

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 app​

After deployment succeeds, use your returned runtime URL without a trailing slash:

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

Expect HTTP 200 at both paths. With the default greeting, the root body is App Service Builder / php-web: Hello (PHP <actual-version>) followed by a newline. Health returns exactly healthy followed by a newline, and unknown routes return HTTP 404. In Overview, confirm the active version. In Versions, check that its source revision matches the commit you intended to deploy.

Push changes and deploy a new version before checking again. The sample's GREETING variable changes public text, not a secret. See variables for how updates reach a new version.

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 source control to change the branch or app root. Use the PHP manifest guidance to adapt the sample's layout.

Last updated on