“It works on my machine” — and then you deploy it.

The app is running. Auth works. Data loads. You click around for ten minutes, everything feels good, and you push it to a test server feeling pretty confident about yourself.

Then someone opens the link and cookies aren't being set. The frontend is redirecting to localhost:5173. The “today's events” section is showing tomorrow's data. And your API calls are getting blocked by CORS even though you literally have CORS set up.

Nothing in your code changed. But your environment did — and your code had no idea it was always depending on the environment staying the same.

These are the things that only show up after you leave localhost. Every single one of them I've either hit myself or watched someone else lose hours to.

1. Your cookies were never going to survive deployment

Locally, your frontend and backend are both on the same machine. The browser doesn't care much about cookie restrictions when everything's on localhost. So your auth works perfectly — cookies get set, requests carry them, life is good.

Then you deploy. Your frontend is on one domain, your backend is on another. Suddenly sameSite: 'strict' is blocking cookies from being sent cross-site. secure: trueis killing them if you're not on HTTPS yet. And you get zero error messages — the cookie just quietly doesn't arrive, and your entire auth flow breaks silently.

The fix is to make your cookie config aware of which environment it's running in. Don't hardcode these values:

// config/cookieConfig.js
const isProduction = process.env.NODE_ENV === 'production';

export const COOKIE_OPTIONS = {
  httpOnly: true,       // always on — keeps JS from touching the cookie
  secure: isProduction, // HTTPS only in prod, relaxed in local
  sameSite: isProduction ? 'strict' : 'lax', // strict in prod, lax locally
  maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
};

Then use COOKIE_OPTIONS everywhere you set a cookie instead of writing the options inline. One file, one place to update, works correctly in both environments.

2. You hardcoded localhost somewhere and you don't remember where

Somewhere in your codebase is a URL that has localhost:5173 or localhost:3000written directly in it. Maybe it's in an OAuth redirect. Maybe it's in a navigate()call. Maybe it's in a link you generate dynamically. Locally it works perfectly because that's where your app actually is. After deploy your users are getting sent to your laptop.

On the frontend — stop constructing absolute URLs manually. Use window.location.origin to always get the current domain, whatever it is:

const [origin, setOrigin] = useState('');

useEffect(() => {
  setOrigin(window.location.origin); // reads the actual domain at runtime
}, []);

// now use it wherever you need a full URL
navigate(origin + '/dashboard');
navigate(origin + '/profile?github=success');

On the backend — keep your frontend URL in .env and use it everywhere you redirect:

// .env
FRONTEND_URL=https://yourapp.com

// anywhere in your backend
res.redirect(process.env.FRONTEND_URL + '/profile?github=success');

This sounds obvious until you're staring at a production redirect going to localhost and trying to figure out where the hell it's coming from.

3. Your server thinks it's in America

This one is less common but when it hits you, it's genuinely confusing. You have a feature that fetches data based on today's date — events, logs, daily summaries, whatever. Works perfectly local. After deploy, the results are off by hours. Sometimes you're getting yesterday's data, sometimes tomorrow's.

The reason is that most deployment platforms (Render, Railway, AWS, Vercel serverless) default to UTC or a US timezone. If your users are in IST, that's a 5 hour 30 minute difference. At 11pm IST your server thinks it's still the previous day.

Install luxonand always work in the user's timezone, converting to UTC only when you actually query the DB:

npm install luxon

import { DateTime } from 'luxon';

app.get('/events/today', async (req, res) => {
  // get this from user profile or send it from frontend
  const userTimeZone = 'Asia/Kolkata';

  // calculate start and end of day in the USER's timezone
  const startOfDay = DateTime.now().setZone(userTimeZone).startOf('day');
  const endOfDay   = DateTime.now().setZone(userTimeZone).endOf('day');

  // convert to UTC before hitting the DB (DB stores UTC)
  const startUTC = startOfDay.toUTC().toJSDate();
  const endUTC   = endOfDay.toUTC().toJSDate();

  const events = await Event.find({
    eventDate: { $gte: startUTC, $lte: endUTC }
  });

  res.json(events);
});

4. CORS that works locally but breaks the moment you deploy

You have CORS set up. You know you do. But after deploy every API call from the frontend is getting blocked. Postman works fine — it's just the browser that's angry.

Two reasons this usually happens. First — your CORS origin is still set to localhost:5173 and your frontend is now on a real domain. Second — you have credentials: true on the backend but forgot withCredentials: true on the frontend, so cookies are never actually sent with requests.

// backend — use env variable, not a hardcoded URL
app.use(cors({
  origin: process.env.FRONTEND_URL,
  credentials: true,
}));

// frontend — add this once in your axios config file
import axios from 'axios';
axios.defaults.withCredentials = true;

5. You added a new .env key and forgot to add it on the server

You built a feature locally, added a new environment variable, everything works. You push the code. The feature throws a 500 in prod. You check your code for twenty minutes before realizing process.env.SOME_NEW_KEY is just undefined on the server because you never added it there.

The error has nothing to do with the actual problem. It usually looks like a null reference or a failed API call — not “hey your env variable is missing.”

Simple habit — keep an .env.example file in your repo. Every time you add a key to .env, add it here too with an empty value:

# .env.example — commit this, not your actual .env
MONGO_URI=
JWT_SECRET=
GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=
FRONTEND_URL=
NODE_ENV=

When you deploy, this file is your checklist. Go through it line by line and make sure every key exists on your prod server. Takes thirty seconds and saves you from that specific brand of confusion where everything looks fine but nothing works.

6. Test your prod build before you actually push to prod

The dev server hides a lot. Vite's hot reload doesn't care about broken imports, missing env variables that get baked in at build time, or components that only fail during compilation. You'll find all of this the hard way if you push straight to prod without building first.

Before pushing, run this in your frontend folder:

npm run build   # builds the app — shows linting errors, missing imports, etc.
npm run preview # serves the built app at localhost:4173

Then temporarily add http://localhost:4173 to your backend CORS, point your frontend API URL to your local backend, and actually use the app on port 4173. This is as close to prod as you can get without actually deploying.

// temporarily while testing the build
app.use(cors({
  origin: ['http://localhost:4173', process.env.FRONTEND_URL],
  credentials: true,
}));

7. MongoDB Atlas is silently rejecting your server

This one catches everyone at least once. Your app deploys, the server starts, and every DB query just hangs and eventually times out. Locally your DB connection is fine. In prod it looks like a connection issue but the error message is vague enough that you'll probably check your connection string three times before figuring it out.

Atlas has an IP whitelist. By default it's locked down. Your local IP is probably added from when you set it up. Your deployment server's IP is not.

Go to Atlas → Network Access → Add IP Address. Either add your server's specific IP or — if your deployment IP changes (like on Render free tier) — allow access from anywhere (0.0.0.0/0) and rely on your connection string credentials for security.