DEV Community

Aditya Sorathiya
Aditya Sorathiya

Posted on

The API Worked Locally. Then Production Broke It. 💀

#programming #api #backend #devops 
┌──────────────────────────────────────┐
│ 🧪 API HEALTH CHECK                  │
├──────────────────────────────────────┤
│                                      │
│ 💻 Local                             │
│    GET /api/test                     │
│    → 200 OK ✅                       │
│                                      │
│ ☁️ Production                        │
│    GET /api/test                     │
│    → 500 Internal Server Error 💀    │
│                                      │
└──────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

And that's where the debugging began.

Locally, everything was working exactly as expected. The API responded correctly, the frontend connected, and there were no obvious errors. But after deployment, something had changed.

So what broke?

You know that feeling when everything works perfectly on localhost?

The API responds.
The frontend gets the data.
Authentication works.
You test it five times.

So you deploy it.

And suddenly:

💥 500 Internal Server Error
Enter fullscreen mode Exit fullscreen mode

Nothing changed.

Except… everything.

The classic situation

During development, I had something like:

Frontend → localhost API → Database

I tested the endpoint and got exactly what I expected.

{
  "success": true,
  "data": "Hello from the API"
}
Enter fullscreen mode Exit fullscreen mode

Perfect.

Then I deployed the backend.

Frontend → Production API → Database

And the frontend started throwing errors.

The worst part?

The API worked when I tested some endpoints manually.

That made it even more confusing.

So what actually changed?

A production environment isn't just your local computer moved to the internet.

There are a lot of things that can be different:

  • Environment variables

  • CORS configuration

  • Database connection strings

  • HTTPS vs HTTP

  • Allowed origins

  • File paths

  • Case-sensitive filenames

  • Dependency versions

  • Python/Node versions

  • Proxy configuration

  • Authentication cookies

  • API URLs

  • Deployment-specific filesystem behavior

One tiny assumption in development can become a production bug.

One of my favorite examples: environment variables

Locally, you might have:

API_URL=http://localhost:8000
Enter fullscreen mode Exit fullscreen mode

Everything works.

But your deployed frontend might still be trying to call:

http://localhost:8000
Enter fullscreen mode Exit fullscreen mode

From the user's browser, localhost means their computer, not your server.

So your API isn't even being contacted.

That bug can be surprisingly easy to miss if you're only testing locally.

Another one: CORS

You might test your frontend and backend locally with:

http://localhost:5500
Enter fullscreen mode Exit fullscreen mode

and:

http://localhost:8000
Enter fullscreen mode Exit fullscreen mode

Then production becomes:

https://myapp.com
Enter fullscreen mode Exit fullscreen mode

and:

https://api.myapp.com
Enter fullscreen mode Exit fullscreen mode

Your backend needs to know that the production frontend is allowed to make requests.

A configuration that worked locally isn't necessarily correct for production.

And then there's the database 😭

Your local machine might have:

mongodb://localhost:27017/mydb
Enter fullscreen mode Exit fullscreen mode

Production obviously can't use your laptop's MongoDB.

So you replace it with a hosted database connection string.

Then you discover:

Authentication failed.

Or:

Connection refused.

Or:

Network access denied.

The API code itself might be completely fine.

The environment around it isn't.

The lesson I learned

When something breaks after deployment, don't immediately rewrite the endpoint.

First ask:

"What is different between local and production?"

I now mentally go through something like:

Environment variables
        ↓
API URL
        ↓
CORS
        ↓
Database
        ↓
Authentication
        ↓
Dependencies
        ↓
File paths
        ↓
HTTPS / proxy
        ↓
Production logs
Enter fullscreen mode Exit fullscreen mode

Only after checking those do I start changing application code.

Production is a different environment

This is probably one of the biggest lessons I've learned while building web projects.

"It works on my machine" isn't the end of testing.

It's actually the beginning of a new type of debugging.

Local development tells you:

"The code can work."

Production testing tells you:

"The entire system works together."

And those are two very different things.

What's the strangest "works locally, breaks in production" bug you've encountered?

I'd love to hear the weird ones. 👇

Top comments (0)