Moving an Amplify Gen 2 App from Sandbox to Production

A sandbox is a developer environment. I use it to change data models and functions without treating each experiment as a production release. Production begins when the repository branch, backend stack, generated client configuration, and operational checks point to the same approved commit.

The risky part of an Amplify Gen 2 sandbox-to-production move is environment confusion. A frontend can build cleanly while using an amplify_outputs.json file generated by another sandbox. My release process proves the identity of the backend before and after deployment.

Know what the sandbox owns

A cloud sandbox uses local AWS credentials and creates developer-scoped resources. I give each sandbox a recognizable identifier, inspect the account and region, and avoid using production data. The sandbox is disposable unless I have documented a reason to retain a resource.

I run the app against the sandbox and test the changed model, function, or authorization rule. Passing local checks means the code is ready for branch validation. It does not mean the sandbox should be promoted as production infrastructure.

Regenerate and inspect client outputs

The outputs file tells the frontend which backend endpoints and identity resources to use. I regenerate it for the target environment rather than copying a remembered file. The Amplify fullstack branch deployment documentation documents npx ampx generate outputs for a deployed branch.

I compare the app ID, branch, region, and expected auth/data sections. I keep secrets out of the file and out of source control. A mismatch here often appears as a 401, DNS error, empty list, or login against the wrong user pool.

Make the production branch explicit

I connect a named production branch and document which branch is allowed to update production resources. Feature and staging branches remain isolated. Automatic branch detection can help, but its patterns deserve review so an arbitrary branch cannot acquire production-like permissions.

Environment variables and secrets are set for the branch that consumes them. I do not assume values from a local shell will exist in the hosted build.

Run the same preflight every time

My preflight includes type checking, linting, focused tests, the full test suite, and a production build. I review the Git diff and confirm generated artifacts are expected. If the backend change modifies authorization or data shape, I add a request that proves both allowed and denied behavior.

I record the commit hash with the results. A list of green commands without the commit cannot prove which code passed.

Verify the deployment as a user

After Amplify reports success, I check the deployed commit and request important routes. I sign in with a production test account, read and mutate a safe record, and inspect function logs for errors. Public routes get an anonymous check as well.

I also confirm that staging and production have separate endpoints and data. A quick success response is not enough if the request reached the wrong environment.

Keep cleanup and rollback in the release

I remove unused sandbox resources after the work is merged, subject to the retention policy. For production I document the prior frontend commit, backward compatibility of the backend change, and the restore source for data.

• Identify the AWS account and region.
• Generate outputs for the target branch.
• Run checks against the release commit.
• Verify live identity and data.
• Remove obsolete sandbox resources.

Need help with Amplify?

If your Amplify environments have drifted or a production release keeps pointing at the wrong backend, Terry Hunt Dev offers AWS development and deployment support. Share the branch model and failure symptoms through the contact page.