I came across these terms while learning and thought I understood them. But I didn’t truly understand them until I began shipping code to production for real users.
How did I finally understand the difference between these environments? When did the word “environment” actually click in my head?
It was when I first launched my web application, Voices — a platform where users can share their stories and post story ideas. When I first shipped it, I was using only one database — my production database — for both development and live users.
So what does “production environment” really mean?
The production environment is the version of your web application that the public sees. Think of it as your public store. Anything you ship to production is what your users interact with.
How did I figure this out?
If you’re only working on the frontend, you may not notice this issue. If you don’t push to GitHub, no problem, right? Even when you start working on the backend, you might still not notice anything serious.
But the real challenge begins when you start working with a database.
At that time, I had only one database. I was using the database URL set in my environment variables on Render when I deployed my server, and I was also using that same database in my local .env file.
So anytime I tested my code by adding data to the database, I discovered that it was also being fetched on my deployed site. Users could see the test data and random values I had added.
You don’t “push” database changes to GitHub. Once data is added to the database, it is automatically fetched and displayed to users.
Right there, at that moment, I thought,_ I was cooked._
But one thing about programming is this: there’s always a way out.
So how can this problem be solved?
That’s when we need a second environment — the development environment.
What Does a Development Environment Mean?
A development environment is a space where any changes or data added are visible only to you, the developer. The public cannot see it. It’s your private workspace.
Once you’re satisfied with what you’ve built and tested there, you can then ship it to production.
How Do We Separate These Two Environments?
This was the question I began asking myself when I realized what was happening.
Whenever I worked on a feature that I didn’t want users to see yet, I needed to add test data to check my changes. But when I opened my deployed web application, I saw my test data sitting alongside real user data.
That’s when I knew I had a problem.
Surprisingly, separating the two environments is actually simple.
You need two databases:
One for development
One for production
Every piece of data added to your development database stays in your development environment. It helps you test your code. It does not automatically go to production when you push your code to GitHub.
For me, I have PostgreSQL installed on my computer, so I created my local development database with it. For production, I sometimes use Render, Railway, or Supabase.
It doesn’t matter which service you use. You can create both databases on those platforms, or create your development database locally if you have PostgreSQL installed.
How Do You Use the Two Databases?
I believe you already have an .env file in your backend project.
In your .env file, you use your development database URL in DATABASE_URL.
Then, on the platform where you host your server, you set the production database URL in the environment variables there.
That’s it.
When you’re working in development, any test data goes into your local database.
When users interact with your live application, their data goes into your production database.
But One More Question…
How does the frontend know which database to use?
How does it know whether to connect to development or production when you call an API?
Separating the databases is only half the solution. The app itself needs to know which backend to talk to.
It’s not complicated.
You just need to differentiate the environments in your frontend as well.
In the root of your frontend project, create:
an .env.development file
an .env.production file
The frontend acts like a bridge.
If it points to localhost, it talks to your private workshop.
If it points to your deployed backend URL, it talks to your public store.
In your .env.development file, add your local backend URL, for example:
http://localhost:5000
In your .env.production file, add the deployed backend URL where your server is hosted.
Then create an api.js file that reads the environment variable and uses the correct base URL. React will automatically use the appropriate file depending on whether you're in development or production mode.
And that’s it.
That’s the difference between development and production environments.
I hope this explanation saves you from the stress of realizing too late that you need separate environment URLs and databases when shipping to production.
Understanding this truly helped me while working on my current project for writers. It’s a sprint writing tool with day and time reminders to help writers stay consistent. It also encourages users with weekly and daily progress tracking.
I just started this project, and I hope to keep learning more as I build.
If you have any questions or thoughts, I’d be glad to read them in the comment section. I hope this post helps you better understand development and production environments.
Top comments (0)