Managing Development, Staging, and Production in Amplify
Use Amplify branch deployments with clear promotion rules, environment-specific configuration, and repeatable production checks.
I give each Amplify environment a job. Development supports active backend changes. Staging tests an approved release candidate with production-like configuration. Production serves users and changes only through the release path. Branch names alone do not enforce those rules, so I document permissions and checks around them.
Amplify Gen 2 can deploy frontend and backend resources for connected Git branches. The Amplify fullstack branch deployment documentation describes branch auto-detection and Git-based promotion. I use those features with explicit patterns rather than connecting every temporary branch.
Define what each branch may do
Development can use synthetic records and test integrations. Staging may use production-shaped data but should not send real customer email, charge live payment methods, or write to production APIs. Production uses approved domains, credentials, retention settings, and alarms.
I write these restrictions beside the branch configuration. A developer should know whether a test submission will reach a real mailbox before opening the preview.
Control branch creation and removal
Automatic detection patterns such as dev, staging, and feature/* can create isolated fullstack deployments. I avoid patterns broad enough to deploy untrusted branches with sensitive roles. Closed branches should disconnect so abandoned resources and credentials do not accumulate.
Pull-request previews need the same review. If a preview shares a backend, I label that limitation. If it creates a backend, I confirm the cleanup behavior and service quota.
Separate configuration and secrets
Each branch receives the endpoint, callback URL, sender identity, and secret values appropriate for its job. The source code refers to stable names while the hosting configuration supplies branch values.
I maintain a configuration inventory with the key name, owner, exposure class, and environments where it exists. The inventory contains no secret values. It helps reviewers catch a production-only requirement before merge.
Promote one immutable commit
I promote a commit that already passed staging rather than rebuilding an uncommitted workspace. The release record includes the Git hash, typecheck, lint, test count, build result, and any data migration. If the production branch must receive a merge commit, I verify that exact hash after deployment.
Backend schema changes receive extra review because an old frontend may run during rollout. I favor additive changes before removals and document the compatibility window.
Verify behavior after the console turns green
A green Amplify job confirms its build and deployment steps. I still request the homepage, critical service routes, authentication, a safe read, and one controlled mutation. I check canonical and robots directives for public pages and inspect function errors.
I compare the deployed commit and backend endpoint with the release record. This catches a common failure where the right frontend reached the wrong environment.
Plan rollback by layer
Frontend rollback, backend rollback, and data restore are different actions. I record which prior frontend artifact can be redeployed, whether the schema remains backward compatible, and where the latest tested backup lives.
- Branches have written responsibilities.
- Secrets stay environment-specific.
- Staging uses safe integrations.
- The production commit is recorded.
- Post-deployment checks cover the user journey.
Need help with Amplify?
Terry Hunt Dev helps teams tighten CI/CD and cloud release processes through DevOps consulting and AWS development. Request a deployment review through the contact page.