<p>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.</p>

<h2>Classify each value</h2>

<p>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.</p><p><code>amplify_outputs.json</code> is generated client configuration. I review it and keep credentials out of it rather than describing the whole file as secret.</p>

<h2>Use NEXT_PUBLIC on purpose</h2>

<p>The <a href="https://nextjs.org/docs/app/guides/environment-variables" rel="noopener noreferrer">Next.js environment-variable guide</a> explains that Next.js inlines <code>NEXT_PUBLIC_</code> 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.</p><p>Branch promotion also matters: an inlined staging URL remains staging even if the same artifact later runs under a production domain.</p>

<h2>Read secrets through an approved server path</h2>

<p>I use Amplify Gen 2 secret management for backend resources and Functions through <code>secret()</code> 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 <code>.env.production</code> become part of the deployment artifact.</p><p>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 <a href="https://docs.amplify.aws/nextjs/deploy-and-host/fullstack-branching/secrets-and-vars/" rel="noopener noreferrer">Amplify secrets and environment variables guide</a> documents the Gen 2 backend secret path.</p>

<h2>Do not confuse auth configuration with authority</h2>

<p>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.</p><p>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.</p>

<h2>Inspect the built application</h2>

<p>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.</p><p>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.</p>

<h2>Rotate after a boundary mistake</h2>

<p>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.</p><p>My <a href="/blog/aws-amplify-vs-vercel-nextjs">Amplify and Vercel comparison</a> covers the host configuration and ownership behind that boundary.</p>

<h2>Unsure whether a value belongs in the browser?</h2>

<p>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 <a href="/contact">contact page</a>, or see my <a href="/services/aws-development">AWS services</a>.</p>

Learn what amplify_outputs.json exposes, which Amplify values belong in browser code, and which credentials must remain in server-only secret storage.

Is amplify_outputs.json Secret? Amplify Security Guide

Treat generated Amplify outputs as client configuration while credentials and private provider values remain on the server.

Is amplify_outputs.json Secret? Config vs. Credentials

<p>I classify a value before deciding where to store it. Browser-safe configuration can appear in a built JavaScript bundle. Server configuration belongs to a function or build environment. Credentials, signing keys, and provider tokens use a secret store and never enter source control.</p><p>Amplify Gen 2 has separate paths for function environment variables, function secrets, local sandbox values, and hosted branch settings. Using one <code>.env</code> file for all four creates confusion and increases the chance of shipping a credential.</p>

<h2>Classify values by exposure</h2>

<p>I label each value public, server-only, or secret. A public API base URL may be safe in the browser. A feature flag can be public or server-only depending on whether it reveals unreleased behavior. A database password, email-provider token, or webhook signing key is a secret.</p><p>The word "environment" does not make a value private. Next.js variables exposed to the client and values inserted during a frontend build can be read by users. I review the generated bundle when the boundary is unclear.</p>

<h2>Use function environment values for non-secret settings</h2>

<p>Function settings such as a mode name, safe endpoint, or log level can use the <code>environment</code> property. Amplify generates typed access through <code>$amplify/env/&lt;function-name&gt;</code>, which catches misspelled names during development.</p><p>The <a href="https://docs.amplify.aws/react/build-a-backend/functions/environment-variables-and-secrets/">Amplify environment variables and secrets documentation</a> warns that plain environment values can appear in build artifacts and CloudFormation events. I reserve them for values that are safe in those locations.</p>

<h2>Use the secret mechanism for credentials</h2>

<p>I define a named secret reference in the function resource and set its value for the sandbox or hosted branch. The function receives the value at runtime. I never copy the value into the schema, handler, test fixture, or Trello card.</p><p>Secret names stay stable across environments while values differ. That lets the same code call a test service in staging and the approved service in production without conditional credentials in source files.</p>

<h2>Keep branches independent</h2>

<p>Development, staging, and production receive their own configuration. I document which settings are shared and which must differ, including callback URLs, sender addresses, analytics destinations, and external API endpoints.</p><p>I check the target branch before changing a value. A console label is easy to misread, so the release checklist records the app ID, branch, and key name without recording the secret value.</p>

<h2>Rotate and verify</h2>

<p>A rotation is incomplete until the consumer uses the new value and the old value has been revoked. I update the target environment, deploy or restart the function if required, run a safe request, and confirm the provider saw the new credential. Then I remove the prior credential.</p><p>If a secret may have entered Git, deleting the file is not enough. I rotate the value and review repository history, build logs, artifacts, and any copied support messages.</p>

<h2>Audit the boundary before release</h2>

<p>I search the diff and tracked files for known key names, inspect frontend configuration, and verify that logs redact headers. I also test a missing-secret failure so the function reports configuration trouble without printing the value.</p><ul><li>Every value has an exposure class.</li><li>Secrets use secret references.</li><li>Branches have documented owners.</li><li>Rotation includes revocation.</li><li>Build and runtime logs are reviewed.</li></ul>

<h2>Need help with Amplify?</h2>

<p>Terry Hunt Dev reviews cloud configuration and deployment boundaries through its <a href="/services/aws-development">AWS development service</a>. If you need to separate browser settings from server secrets, describe the environments through the <a href="/contact">contact page</a> without sending any credential values.</p>

Learn where Amplify Gen 2 environment variables and secrets belong, how branch values differ, and how to prevent credentials from reaching source control.

Environment Variables and Secrets in Amplify Gen 2

Separate public configuration, function settings, and secrets across Amplify Gen 2 sandboxes and branch deployments.

<p>I decide what an AI assistant needs before I provide code, logs, screenshots, or tool access. Most debugging work needs structure and error context, not a customer's message, full token, private hostname, or complete production record.</p><p>Redaction is part of preparing the task. I replace identifying values with consistent synthetic ones so relationships remain visible without exposing the original data.</p>

<h2>Classify the material</h2>

<p>I mark credentials, personal data, client-confidential data, internal infrastructure, proprietary code, and public information. The classification determines whether the material can be used, must be reduced, or should stay out of the workflow.</p><p>A value can be harmless alone and identifying in combination. A timestamp, rare route, and exact error may reveal a customer incident even after the name is removed.</p>

<h2>Redact while preserving structure</h2>

<p>I replace tokens with <code>TOKEN_REDACTED</code>, accounts with stable fictional IDs, domains with <code>example.invalid</code>, and user records with synthetic fixtures. Consistent replacements let the assistant trace one identity across a sanitized log.</p><p>I remove authorization headers and query strings before copying a request. Screenshots receive the same review as text.</p>

<h2>Use the smallest code scope</h2>

<p>I share the failing function, type, test, and necessary configuration instead of an entire proprietary repository when broad access is not required. If Codex has repository access, the task and filesystem scope still state what it may inspect and change.</p><p>External systems remain read-only during diagnosis unless the user authorizes a bounded write.</p>

<h2>Review generated commands</h2>

<p>I resolve targets before executing commands that deploy, delete, rotate, migrate, or send messages. I reject unresolved variables, broad globs, and output that may print environment values. Commands run in a non-production environment first when possible.</p><p>A model can produce syntactically correct destructive commands. Human review supplies authority and context.</p>

<h2>Respond to accidental exposure</h2>

<p>If a secret enters a prompt, log, commit, or screenshot, I revoke or rotate it. Deleting the visible copy does not prove downstream copies disappeared. I review access logs and affected systems according to the incident plan.</p><p>Client data exposure follows the organization's privacy and notification procedure. The developer should not improvise legal conclusions.</p>

<h2>Use a pre-share checklist</h2>

<p>I pause before every upload or pasted block and search for common credential formats, email addresses, hostnames, account numbers, and message content. Automated secret scanning helps but does not replace context review.</p><ul><li>Only necessary files are in scope.</li><li>Examples use synthetic values.</li><li>Tool permissions match the task.</li><li>Commands have explicit targets.</li><li>Exposed credentials are rotated.</li></ul>

<h2>Need a safer development workflow?</h2>

<p>Terry Hunt Dev can help teams define safer automation and development practices through <a href="/services/devops-consulting">DevOps consulting</a>. Discuss the policy through the <a href="/contact">contact page</a> without pasting private logs or credentials.</p>

Improve AI coding assistant security with rules for redacting secrets and client data, using synthetic examples, limiting access, and reviewing commands.

Keeping Secrets and Client Data Out of AI Coding Workflows

Redact credentials and customer data, use synthetic examples, restrict tool scope, and review commands before AI-assisted work changes systems.

Secrets Resources & Benchmarks

Is amplify_outputs.json Secret? Config vs. Credentials

Environment Variables and Secrets in Amplify Gen 2

Keeping Secrets and Client Data Out of AI Coding Workflows

Need hands-on help with Secrets?