Path-based selective build triggering for monorepo apps in Amplify Hosting

[shivennn]

Before opening, please confirm:

• I have checked to see if my question is addressed in the FAQ.
• I have searched for duplicate or closed issues.
• I have removed any sensitive information from my code snippets and submission.

Amplify Hosting feature

Build settings

Is your feature request related to a problem? Please describe:

We have a monorepo with 5 Amplify Hosting apps, each connected to the same
GitHub repository with distinct appRoot paths (packages/next, packages/cmbs,
packages/cre, packages/lv, packages/dm).

Currently, every push or pull request to the repository triggers a build
pipeline for ALL 5 connected Amplify apps — regardless of which packages
actually changed. This causes the following problems:

1. UNNECESSARY BUILDS ON PULL REQUESTS
   When a change is made to only one app (e.g., packages/cre), all 5 Amplify
   apps initiate a pipeline. Although AMPLIFY_DIFF_DEPLOY=true skips the build
   step for unchanged apps, the pipeline still initiates (clone, cache
   retrieval) adding ~6-10 seconds of overhead per app on every PR.

2. NOISY PR PREVIEW DEPLOYMENTS
   Amplify generates preview deployments and posts GitHub PR comments with
   preview URLs for ALL connected apps — including apps whose code has not
   changed. This creates confusion during code reviews as reviewers see 5
   preview URLs when only 1 app was modified.

3. ALL APPS DEPLOY ON MERGE TO MAIN
   When a PR is merged, all 5 apps trigger production deployments
   simultaneously in a non-deterministic order. This means the app that
   actually contains changes is not guaranteed to deploy first, increasing
   time-to-availability. Total deployment time currently exceeds 20 minutes
   in some cases.

Describe how you'd like this feature to work

We would like Amplify Hosting to support path-based selective build triggering
for monorepo setups. Specifically:

1. PATH-BASED WEBHOOK FILTERING
   Allow each Amplify app to define one or more watch paths. Only trigger a
   build pipeline when a push or PR contains changes within those paths.

   Example configuration in amplify.yml:

   applications:
   - appRoot: packages/cre
   watchPaths:
   - packages/cre/**
   - packages/shared/**
   frontend:
   ...

2. SELECTIVE PR PREVIEWS
   Only generate PR preview deployments and post GitHub PR comments for apps
   whose watchPaths contain changes. Apps with no relevant changes should not
   initiate a pipeline, generate a preview URL, or post a GitHub comment.

3. MULTIPLE PATHS FOR AMPLIFY_DIFF_DEPLOY_ROOT
   Allow AMPLIFY_DIFF_DEPLOY_ROOT to accept a comma-separated list of paths
   so apps that depend on shared packages can monitor multiple directories:

   AMPLIFY_DIFF_DEPLOY_ROOT=packages/cre,packages/shared

4. DEPLOYMENT ORDERING (NICE TO HAVE)
   Provide a way to define deployment priority across apps in the same
   repository so the most critical or most recently changed app deploys first.

Current Workaround

Since these features are not natively available, we implemented a GitHub
Actions workflow to replace Amplify's native webhook triggers:

Step 1 — Disable Amplify's native triggers:

• Disabled auto-build on all Amplify apps via:
  aws amplify update-branch --no-enable-auto-build
• Disabled PR previews on all Amplify apps via:
  aws amplify update-branch --no-enable-pull-request-preview

Step 2 — GitHub Actions workflow (.github/workflows/amplify-selective-build.yml):

• Uses dorny/paths-filter to detect which packages/* directories changed
• Includes packages/shared as a dependency for all apps
• On PR opened/updated:
  • Creates an Amplify branch using the source git branch name
  • Calls aws amplify create-branch + start-job ONLY for changed apps
  • Preview URL: https://..amplifyapp.com
• On PR closed:
  • Calls aws amplify delete-branch to clean up preview branches
• On push to main:
  • Calls aws amplify start-job --job-type RELEASE ONLY for changed apps

This workaround is functional but adds operational overhead:

• Requires managing AWS credentials as GitHub secrets
• Requires IAM permissions: StartJob, CreateBranch, DeleteBranch, GetBranch
• Does not replicate Amplify's native GitHub status checks on PRs
• Requires manual updates when new apps are added to the monorepo
• Adds workflow maintenance burden that should not be necessary

Native support for path-based filtering in Amplify Hosting would eliminate
this workaround entirely and significantly improve the developer experience
for teams working with monorepos.

Repository structure for reference:

├── amplify.yml
├── node_modules
├── package-lock.json
├── package.json
├── packages

packages
├── cmbs
│   ├── app
│   ├── package.json
│   ├── public
│   └── src
├── cre
│   ├── app
│   ├── package.json
│   ├── public
│   └── src
├── dm
│   ├── app
│   ├── package.json
│   ├── public
│   └── src
├── lv
│   ├── index.html
│   ├── package.json
│   ├── public
│   ├── src
│   └── vite.config.js
├── next
│   ├── app
│   ├── package.json
│   ├── public
│   └── src
└── shared
    ├── package.json
    └── src

[github-actions]

This has been identified as a feature request. If this feature is important to you, we strongly encourage you to give a 👍 reaction on the request. This helps us prioritize new features most important to you. Thank you!