feat: Add --standalone flag for deployments without Amplify Hosting

[adrianjoshua-strutt]

Add standalone deployment type for deploying Gen2 backends without Amplify Hosting

Today, deploying an Amplify Gen2 backend requires Amplify Hosting. This PR adds a standalone deployment type that lets you deploy Gen2 backends from any CI/CD system (GitHub Actions, Jenkins, CodePipeline, etc.) using ampx pipeline-deploy --standalone --stack-name .

Standalone deployments skip the BranchLinker (no Amplify app needed) and use the provided stack name as the CloudFormation namespace.

Corresponding docs PR, if applicable:

Validation

Unit Tests

• Added unit tests for WebAuthn relyingPartyId behavior in standalone deployments (throws on AUTO, accepts explicit domain) in auth-construct/src/construct.test.ts
• Added unit tests for standalone deployment tag propagation in backend/src/default_stack_factory.test.ts
• Added unit test for standalone backend factory initialization in backend/src/backend_factory.test.ts
• Updated existing pipeline-deploy command tests for the standalone flow in cli/src/commands/pipeline-deploy/pipeline_deploy_command.test.ts
• Also added new test file for CFN deployment progress logger (cli-core/src/loggers/cfn-deployment-progress/cfn_deployment_progress_logger.test.ts) covering nested stack name resolution for standalone/sandbox, progress tracking, failure display, and CDKMetadata filtering. This did not exist before and are not 100% related to this change. But they are required to verify this change does not break the CLI logging for other workflows.

In-Memory Integration Tests

• Added standalone_deployment.test.ts. synthesizes a standalone backend with explicit WebAuthn relyingPartyId and verifies correct CloudFormation output with no Amplify Hosting artifacts (no AWS::Amplify::App, AWS::Amplify::Branch, or amplifyapp.com references)
• Added standalone_deployment_auto_webauthn.test.ts. verifies that using WebAuthn AUTO (webAuthn: true) under standalone deployment throws an error, since AUTO requires Amplify Hosting to resolve the relying party ID

E2E Tests

• Updated test_project_base.ts deploy() to route standalone type identifiers to ampx pipeline-deploy --standalone --stack-name <namespace> --branch <name>

• Added standalone_data_storage_auth.deployment.test.ts and standalone_deployment.test.template.ts. A standalone deployments that deploys via ampx pipeline-deploy --standalone --stack-name <name>, verifies the CloudFormation stack reaches a successful state, and asserts no Amplify Hosting resources (AWS::Amplify::App, AWS::Amplify::Branch) are present

• Note on comprehensive standalone E2E test: A standalone E2E test reusing DataStorageAuthWithTriggerTestProjectCreator (the same project used by sandbox and branch deployment tests) is included but commented out. The currently published @aws-amplify/data-construct bundles @aws-amplify/backend-output-storage@1.1.5 in its own node_modules, which throws on the new "standalone" deployment type context value. Because data-construct ships with its own bundled copy of backend-output-storage, there is no way to override it at install time. Even though the local workspace has the updated version, npm resolves the bundled copy from within data-construct's dependency tree. This creates a cross-repo sequencing issue: backend-output-storage must be published first (via this PR), then data-construct in amplify-category-api needs to update its bundled dependency and publish a new version. Once that happens, this test can be uncommented to verify the full stack (data, storage, auth, lambdas, secrets) works identically via an E2E test under standalone deployment.

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[changeset-bot]

🦋 Changeset detected

Latest commit: 356f015

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@aws-amplify/plugin-types	Patch
@aws-amplify/platform-core	Patch
@aws-amplify/backend	Patch
@aws-amplify/backend-deployer	Patch
@aws-amplify/backend-output-storage	Patch
@aws-amplify/cli-core	Patch
@aws-amplify/backend-cli	Patch
@aws-amplify/auth-construct	Patch
@aws-amplify/ai-constructs	Patch
@aws-amplify/backend-auth	Patch
@aws-amplify/backend-data	Patch
@aws-amplify/backend-function	Patch
@aws-amplify/sandbox	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[sarayev]

Do we document these in our docs? It should be there for the customers to access easier.

[adrianjoshua-strutt]

Good point. While this is now enforced via an Exception, we should explicitly mention it in our docs.

[sarayev]

Could you please add unit tests for this change? How do we plan to test this feature end-to-end?

[adrianjoshua-strutt]

Could you please add unit tests for this change? How do we plan to test this feature end-to-end?

Yes, I will add unit tests as soon as it is clear on how we will implement the feature. This branch is currently mostly there to demonstrate how we can bypass hosting and release a snapshot, that is used for demos.

End-to-end testing could be done via integration tests, but would require significant effort. This is something that we would have to discuss as part of the feature release. It is not yet clear if we will release this flag in the near future.