DEV Community: Leo Brown

7 Things I Check When a React App Works Locally but Breaks in Production

Leo Brown — Fri, 04 Sep 2026 19:28:13 +0000

7 Things I Check When a React App Works Locally but Breaks in Production

One of the most annoying frontend problems is this:

Your app works perfectly on localhost.

Then you deploy it.

And suddenly:

API requests fail
routes return 404
environment variables are missing
images disappear
authentication redirects break
everything works on your machine, but nowhere else

This happens often enough that I now go through roughly the same checklist every time.

Here are the things I usually check first.

1. Environment variables

Local development makes environment variables feel simple because .env files are always nearby.

Production is different.

A variable may:

not exist on the server
use a different name
contain an outdated URL
not be exposed to the browser
have been changed without rebuilding the app

For example, in Vite:

VITE_API_URL=https://api.example.com

and:

const apiUrl = import.meta.env.VITE_API_URL;

If you accidentally use:

API_URL=https://api.example.com

the variable will not automatically be exposed to client-side code.

Next.js has a similar distinction:

NEXT_PUBLIC_API_URL=https://api.example.com

is available in the browser, while:

API_URL=https://api.example.com

is normally server-side only.

When something works locally but fails after deployment, I always inspect the actual production environment before changing application code.

2. Hardcoded localhost URLs

This one is extremely common.

During development, code slowly accumulates things like:

fetch("http://localhost:3001/api/users");

or:

const socket = new WebSocket("ws://localhost:4000");

Everything works locally because all services are running on the same machine.

In production, localhost means the user's own machine or the production server, depending on where the code executes.

Neither is usually what you want.

A better approach is to keep URLs in configuration:

const apiUrl = import.meta.env.VITE_API_URL;

fetch(`${apiUrl}/api/users`);

I also search the whole project for:

localhost
127.0.0.1
http://

before deploying.

It catches more issues than you might expect.

3. CORS

A request that succeeds locally can fail immediately when the frontend and backend are hosted on different origins.

Example:

Frontend:
https://app.example.com

API:
https://api.example.com

The backend needs to allow requests from the frontend origin.

A typical Express configuration might look like:

import cors from "cors";

app.use(
  cors({
    origin: "https://app.example.com",
    credentials: true,
  })
);

During debugging, I open the browser network panel and inspect the request directly.

If the browser says something like:

blocked by CORS policy

then changing React code usually will not fix the problem.

The fix belongs on the API side.

4. Client-side routing

Single-page applications often have routes like:

/
/dashboard
/settings
/users/123

Navigation inside the app works because React Router handles it.

But refreshing:

https://example.com/dashboard

may return:

404 Not Found

Why?

Because the web server tries to find an actual /dashboard file.

For a client-side SPA, the server usually needs to return index.html for unknown application routes.

For Nginx, that may look like:

location / {
    try_files $uri $uri/ /index.html;
}

Platforms like Vercel, Netlify, Cloudflare Pages, and others have their own rewrite rules.

If navigation works but refreshing a route does not, routing configuration is one of the first things I check.

5. HTTP vs HTTPS

Browsers are much stricter once your site is served over HTTPS.

For example:

https://example.com

calling:

http://api.example.com

can be blocked as mixed content.

WebSockets have the same issue.

Instead of:

new WebSocket("ws://api.example.com");

you may need:

new WebSocket("wss://api.example.com");

A page can appear completely normal while some background functionality silently fails because the browser blocks insecure requests.

The console usually reveals this quickly.

6. File name case sensitivity

This bug can be surprisingly confusing.

On some local development systems, this may appear to work:

import Header from "./components/header";

even if the real file is:

Header.jsx

But a Linux production server may treat:

Header.jsx

and:

header.jsx

as different files.

The deployment build then fails, or the module cannot be resolved.

I try to keep import paths exactly aligned with filenames:

import Header from "./components/Header";

This problem is especially easy to introduce when renaming files only by changing capitalization.

Git may not always detect the change the way you expect.

One workaround is:

git mv Header.jsx HeaderTemp.jsx
git mv HeaderTemp.jsx header.jsx

7. Production build behavior

Development mode is not production mode.

React, Vite, Next.js, and bundlers can behave differently after optimization.

Before blaming the hosting provider, I build the application locally.

For Vite:

npm run build
npm run preview

For Next.js:

npm run build
npm start

This catches problems such as:

missing imports
invalid environment variables
SSR-only errors
browser-only APIs used on the server
build-time data fetching failures
TypeScript errors
incorrect asset paths

If the production build already fails locally, deployment is not the real problem.

My debugging order

When a deployment behaves differently from localhost, I usually check things in this order:

1. Browser console
2. Network requests
3. Production environment variables
4. API URLs
5. CORS
6. Routing/rewrite rules
7. HTTPS / mixed content
8. Production build logs

This order saves me from randomly changing code.

The browser console and network panel alone often reveal the issue within a few minutes.

A small habit that helps

I try to avoid treating production configuration as something I think about only during deployment.

Instead, I keep local development reasonably close to production:

use environment variables from the start
avoid hardcoded URLs
test production builds locally
keep frontend and backend configuration separate
use HTTPS-compatible URLs
check routes with direct page loads

The closer the environments are, the fewer surprises appear later.

Final thought

When an app works locally but fails in production, the React code itself is often fine.

The problem is usually somewhere around it:

configuration
networking
routing
security
environment
build process

How I test my React app on real devices without deploying it

Leo Brown — Sat, 29 Aug 2026 20:37:23 +0000

How I test my React app on real devices without deploying it

I recently needed to test a React app outside my own computer. Opening another browser tab wasn't enough. I wanted to use the app on my phone, try it on another device, and sometimes share the current build without deploying it first.

The app was running locally:

npm run dev

Depending on the project, that usually gives me an address like this:

http://localhost:3000

But localhost only exists on my machine.

What I tried

There are several ways to expose a local development server to the internet. I tried a few tunneling services and approaches, and they worked, but I wanted something simpler for this workflow.

My requirements were straightforward:

one command to start a tunnel;
HTTPS without configuring certificates;
no deployment;
a URL I could open from my phone;
something convenient for React and Vite development;
preferably a hostname I could keep instead of receiving a new URL every time.

I ended up using PortPreview.

Starting a tunnel

There isn't much to configure. With the React development server already running, I can expose its port from the terminal:

npx portpreview 3000

My local address:

http://localhost:3000

is then available through a public HTTPS URL. I can open that URL on my phone and test the app there without making a temporary deployment.

Why I use it for React development

Chrome DevTools responsive mode is useful, but it doesn't cover everything. Some things need a real device:

touch interactions;
mobile Safari and Chrome behavior;
viewport quirks;
authentication redirects;
camera or browser APIs;
network behavior;
links opened from messaging apps;
sharing a work-in-progress build with someone else.

Instead of pushing a branch and waiting for a preview deployment, I leave the React dev server running and expose it directly:

Edit React code
      ↓
Local dev server
      ↓
PortPreview tunnel
      ↓
Real phone / remote browser

Changes from the local server appear through the tunnel immediately, so the workflow still feels like local development.

Why I kept using it

PortPreview lets me reserve one domain for free. That matters more than I expected because temporary URLs get annoying once you use tunnels regularly.

A tunnel URL may be configured in several places:

OAuth callbacks;
webhook endpoints;
API dashboards;
test integrations;
mobile devices;
bookmarks;
configuration files.

With a reserved hostname, I don't have to update those places whenever I restart my development environment. The free plan lets me reserve one domain permanently, which covers many personal development and testing projects.

It isn't limited to React

I started using PortPreview for a React app, but it works with anything listening on a local port, including:

React / Vite
Next.js
Vue
Angular
Node.js
Express
NestJS
local APIs
webhook handlers

For example, I can expose an API running on port 3000 with:

npx portpreview 3000

The API can then receive external requests without being deployed. This is particularly handy for services that need to send requests back to my machine.

Tunnels and preview deployments serve different jobs

I still use preview deployments when a team needs a stable environment or when the app must stay online independently of my computer.

A preview deployment looks like this:

code → commit → push → build → deploy → test

A local tunnel is shorter:

code → localhost → test

For a quick test, I usually prefer the second workflow.

Using a permanent subdomain

After trying the random tunnel URL, I wanted a stable address for the project. PortPreview lets me reserve a subdomain and use it when starting the tunnel:

npx portpreview 3000 --subdomain my-project --token pp_live_...

This gives the project a predictable URL instead of a new random address each time. I can also save the token instead of passing it with every command:

npx portpreview config set-token pp_live_...

After that, starting a tunnel takes one command:

npx portpreview 3000

My normal workflow is:

Run the React app
      ↓
npx portpreview 3000
      ↓
Open the public HTTPS URL
      ↓
Test on a real device

When a project needs a stable URL, I use the reserved subdomain. Once the initial setup is done, exposing a local app is a one-command job.

Final thoughts

There are plenty of established tunneling tools, and no single option will suit everyone. For my React workflow, I wanted as little friction as possible: start the app, run one command, get an HTTPS URL, and open it on a real device.

The permanent free hostname also solves one of the more irritating parts of using temporary tunnels regularly.

If you're dealing with the same problem, take a look at PortPreview. I'm also curious what other developers use for local React testing and webhook development.