ShipReady rates this medium. Fix soon. Meaningfully weakens a defence or degrades how the site works.

Across the sites ShipReady has scanned where this check completed, 13% · n=31 · as of 15 September 2026.

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

All checks

Production Readinessmediumlocalhost-url-in-productionchecked on every page we scan

Production build points at localhost

Your published JavaScript contains the value.

13% · n=31 · as of 15 September 2026 of sites ShipReady scanned had this, counted across sites where this check completed.

Why it matters

Your published JavaScript contains the value. A request to localhost from a visitor's browser goes to THEIR machine, not your server, so whatever this powers — an API call, an image, an auth redirect — fails for every real user while continuing to work perfectly on the developer's own laptop. This is the classic environment-variable mistake: the value was never swapped for production, and nothing errors at build time to say so.

How ShipReady detects it

Launch signals carried by a PAGE's own markup: basic metadata, and a default framework title left in place. Genuinely per-page - a polished homepage routinely hides a /pricing that still says "Create Next App", which is exactly the defect this catches. Reads only the already-fetched HTML and issues no requests of its own.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.10.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

Your production build ships a localhost URL (the affected URLs). A visitor's browser resolves localhost to their OWN machine, so this call fails for every real user while working fine on your laptop — which is why it survives. Find where the value comes from: it is almost always an API base URL read from an environment variable (NEXT_PUBLIC_API_URL, VITE_API_URL or similar) that was set for local development and never given a production value in your hosting provider's dashboard. Set the production value in Vercel/Netlify/Railway env settings, redeploy, and confirm the string is gone from the built bundle. To stop it recurring, make the code fail loudly when the variable is missing at build time instead of falling back to a localhost default.

Frequently asked questions

What does "Production build points at localhost" mean?: Your published JavaScript contains the value.
How serious is it?: ShipReady rates this medium. Fix soon. Meaningfully weakens a defence or degrades how the site works.
How common is this?: Across the sites ShipReady has scanned where this check completed, 13% · n=31 · as of 15 September 2026.
How do I fix it?: Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
Can I check my own site?: Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

Run this check on your site

ShipReady checks this and 193 other things across up to ten pages of your site, with an AI-ready fix for each. Free, no signup.

Scan your site free View pricing