Four Failures I Kept Repeating on AWS Amplify — Full env Replacement, Green Build but 500 at Runtime, Silent Outages, Domain Migration

In April to July 2026, the author experienced several recurring issues while running Next.js products on AWS Amplify Hosting. These four categories of failures were sorted into a detailed article, which is broken down below with the key facts presented in a new order for better readability.

Failure 1: update-app replaces all of your env

When attempting to add a single environment variable, the author inadvertently replaced the entire environment-variable map using the update-app command. This replacement feature does not append new variables but instead replaces the entire map, wiping out existing values such as ONION_CLIENT_ID. The affected production authentication was not restored until the environment was rebuilt after editing, which is a critical oversight.

The author now advises confirming whether an env-manipulation API appends or replaces and to rebuild the application after editing env. Build passing does not guarantee runtime functionality, especially in SSR environments where branch environment variables are not passed to the runtime Lambda.

Failure 2: The build passes, but it fails at runtime

This category highlights a more insidious issue. Amplify SSR does not forward branch environment variables to the runtime Lambda, and NEXT_PUBLIC_* variables are baked into the build time. A passing build does not guarantee that the app will run correctly at runtime, as it can return 500 errors for missing env variables. To address this, the author recommends baking env into the .env.production file during the preBuild phase or using a runtime resolution layer for env variables.

This ensures that failures are not hidden until runtime. Additionally, the author emphasizes the importance of not hiding failures and utilizing build-once + runtime injection for a reliable environment management system.

Failure 3: Failures progress silently

This category deals with outages that remain undetected due to inadequate monitoring or testing. One notable instance involved the admin console going blank, but the issue went unnoticed because access was blocked silently, resulting in HTTP 200 responses with sample data instead of error messages. To prevent such silent failures, the author suggests fail-loud practices, ensuring that errors are not hidden behind a 200 response.

They also recommend staging promotion, which involves promoting changes to a staging environment before deploying to production, and implementing authenticated end-to-end (E2E) testing to catch failures early in the development cycle.