Is amplify_outputs.json Secret? Config vs. Credentials

Amplify outputs contain browser configuration, not provider credentials. The useful question is where each remaining value belongs: generated JSON, a public Next.js variable, or server-side storage. A synthetic canary string in the production build catches accidental client bundling without exposing a real credential during the test.

Classify each value

I classify configuration before choosing a file. Browser code needs public endpoints, region identifiers, and Cognito client configuration. A provider token, signing secret, or admin credential stays on the server. The name of an environment variable does not enforce that boundary.

amplify_outputs.json is generated client configuration. I review it and keep credentials out of it rather than describing the whole file as secret.

Use NEXT_PUBLIC on purpose

The Next.js environment-variable guide explains that Next.js inlines NEXT_PUBLIC_ values into the browser bundle at build time. I reserve that prefix for values I am prepared to publish. Renaming a secret with the prefix turns it into client code.

Branch promotion also matters: an inlined staging URL remains staging even if the same artifact later runs under a production domain.

Read secrets through an approved server path

I use Amplify Gen 2 secret management for backend resources and Functions through secret() references. I do not assume those values are available to Next.js Server Actions or Route Handlers. Amplify Hosting does not expose build variables to SSR code by default, and values written into .env.production become part of the deployment artifact.

For AWS-resource access from SSR compute, I prefer an IAM SSR Compute role. Other provider credentials need a reviewed server-side retrieval design. The Amplify secrets and environment variables guide documents the Gen 2 backend secret path.

Do not confuse auth configuration with authority

A Cognito user-pool ID or app-client ID can appear in browser configuration. Possessing those identifiers does not grant admin access. Tokens and backend authorization decide what a caller can do.

I still avoid publishing unrelated account details and private domain names in tutorials. Public configuration should be intentional, not an excuse to copy a full production file into an article.

Inspect the built application

I search the client build for known secret canaries and private environment names. I also inspect source maps, generated JSON, build logs, and error responses. A secret can leak through logging even when no component imports it.

After deployment I use a synthetic, nonsecret value to verify the SSR configuration path and confirm that browser assets do not contain it. Real credentials stay in the approved Function, IAM role, or reviewed server-side retrieval path.

Rotate after a boundary mistake

If a credential reaches source control, a client bundle, or a public build log, I revoke it before cleaning the repository. Deleting the string does not invalidate copies already downloaded. I then trace the import path and add a regression check.

My Amplify and Vercel comparison covers the host configuration and ownership behind that boundary.

Unsure whether a value belongs in the browser?

I can trace an Amplify value through generated outputs, the server environment, and the client bundle without exposing the credential itself. Send the variable names and sanitized build context through the contact page, or see my AWS services.