A Next.js app can finish building and still fail to deploy. I found that out while adding Netlify as another host for a project that already ran on Vercel and Cloudflare.

Netlify detected Next.js automatically and used its Next.js Runtime. I didn’t need to add a separate adapter. The first deploy built the app, generated its routes, and packaged the server function. Then it stopped before publishing because the secret scanner found values it considered exposed.

That was the first useful distinction: a successful next build does not mean a successful Netlify deploy. The build and the platform’s later checks are separate stages, and the deploy log tells you which one stopped.

Rename the app’s S3 variables

Netlify reserves several AWS environment variable names, including AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, and AWS_ENDPOINT_URL_S3. The app used those names for its S3-compatible object storage settings, so Netlify would not accept them.

I renamed the app-level variables to:

S3_ACCESS_KEY_ID
S3_SECRET_ACCESS_KEY
S3_REGION
S3_ENDPOINT_URL

The code and .env.example now use those names. Because these are application settings, each host needs the new names too; changing the code alone is not enough. The access key and secret key remain credentials and should stay protected.

Don’t mark every variable as a secret

The next Netlify check scanned the repository and generated build output. It flagged several values: some were real credentials, while others were ordinary configuration such as the image provider, storage region, and public Turnstile site key. It also found values in .dev.vars and in generated files.

The right response is to review the location and purpose of each match. A public site key or a region setting may be expected in client-visible output; an authentication secret or API key is not. Keep real credentials protected, correct any real secrets included in source or output, and remove real values from example files. For a confirmed false positive, use Netlify’s documented scan settings narrowly. Turning off secret scanning would hide the warning without resolving what caused it.

Switch this build from Turbopack to Webpack

After the secret scan was addressed, the next deploy failed during compilation. The log showed 28 errors, but they all had the same root cause: while processing next/font/google, Turbopack tried to resolve an internal module named @vercel/turbopack-next/internal/font/google/font. That module was unavailable in this Netlify build. The first import trace pointed to the site’s font page.

Next.js 16 uses Turbopack for next build by default. For this Netlify build, I switched the build command to:

pnpm exec next build --webpack

That keeps the repo’s regular build script available to the other hosts while opting Netlify into Next.js’s supported Webpack build option. If you prefer to use Turbopack everywhere, another route is to self-host the font with next/font/local and test the resulting build on each platform.

Separate warnings from the failure

The missing build cache and Sentry’s missing upload token were warnings too. Neither stopped compilation. The fatal error was the one that ended the current stage: first the secret scan, then the Turbopack font resolution.

What I’d check on the next host

When adding a deployment platform, I now work through the logs stage by stage:

  1. Check that the platform accepts the environment variable names.
  2. Confirm the framework build itself completes.
  3. Read the platform’s post-build checks, including secret scanning.
  4. Separate unrelated warnings from the actual failing stage.
  5. Test the deployed routes and services after publishing.

Most of the app was already portable. The work was finding two platform-specific assumptions—reserved environment variable names and a bundler integration—and making the build command explicit for Netlify.