<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><code>getStaticProps</code> still works in the Next.js Pages Router. It pre-renders a page at build time and serializes the returned props for the browser. That makes it a good fit for public data that can be known before a request, such as documentation, catalog pages, and CMS articles.</p>

<p>It is not an App Router API. New App Router work uses server components, <code>fetch</code> caching, and route-level revalidation instead. Keep that boundary clear when you maintain a mixed Next.js application.</p>

<h2>Fetch public data at build time</h2>
<pre><code>export async function getStaticProps() {
  const response = await fetch("https://example.com/api/articles")
  if (!response.ok) throw new Error(`Article request failed: ${response.status}`)

  return {
    props: { articles: await response.json() },
    revalidate: 300,
  }
}</code></pre>
<p>The function runs on the server. Its returned props do not stay private, though. Next.js includes them in the rendered page data, so never return tokens, private customer fields, or unrestricted database records.</p>

<h2>Read local files directly</h2>
<p>Build-time code can read a repository file or call a server-only library directly. Avoid calling your own API route from <code>getStaticProps</code>; importing the shared data function removes an extra network hop and keeps one implementation.</p>
<pre><code>import { loadArticles } from "../lib/articles"

export async function getStaticProps() {
  return { props: { articles: await loadArticles() } }
}</code></pre>

<h2>Generate dynamic routes with getStaticPaths</h2>
<p>A dynamic Pages Router file such as <code>pages/articles/[slug].tsx</code> pairs <code>getStaticProps</code> with <code>getStaticPaths</code>. The path function chooses which pages build ahead of time. The props function loads one record and should return <code>notFound: true</code> when the slug does not exist.</p>

<h2>Use ISR for public data that changes</h2>
<p>The <code>revalidate</code> value enables Incremental Static Regeneration. After that interval, the next eligible request can trigger regeneration while the existing page remains available. Treat the interval as a freshness decision, not a guarantee that a page changes at an exact second.</p>

<h2>Handle failures deliberately</h2>
<p>A failed required build-time request should usually fail the build so stale or incomplete content does not deploy unnoticed. For optional data, return an explicit empty state and monitor the failure. Catching every error and returning <code>null</code> can turn a broken integration into a successful deployment.</p>

<h2>Check these boundaries</h2>
<ul><li>The page lives in the Pages Router.</li><li>The data is public and safe to serialize.</li><li>Missing records return <code>notFound</code>.</li><li>Dynamic paths have an intentional fallback policy.</li><li>ISR freshness matches the publishing workflow.</li></ul>

<p>See the current <a href="https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-props" rel="noopener noreferrer">Next.js getStaticProps documentation</a> for the supported return values. If you are planning a broader application change, review <a href="/services/nextjs-development">Next.js development services</a> or <a href="/contact">share the route and data requirements</a>.</p>

Use Next.js getStaticProps for build-time data, dynamic routes, preview content, and ISR while keeping secrets out of serialized page props.

Next.js getStaticProps Patterns for the Pages Router

Use getStaticProps for public build-time data, dynamic Pages Router routes, preview content, and incremental static regeneration without exposing secrets.

Environment Variables Resources & Benchmarks

Environment Variables and Secrets in Amplify Gen 2

Practical getStaticProps Patterns for the Next.js Pages Router

Need hands-on help with Environment Variables?