Environments: Development, Staging, and Production

Objectives

By the end of this lesson, you should be able to:

• Define development, staging, and production, and explain what actually differs between them
• Explain why the same source code needs to behave differently across environments
• Identify what should never differ between environments

💡 Why this matters: Every course in this track has run in exactly one environment, a laptop, with one developer, one database, one set of assumptions. A real application runs in at least two, often three, distinct environments, each with different data, different traffic, and different consequences for a mistake.

The Three Common Environments

Development is where code is written and run locally, fast feedback, verbose logging, a small or fake dataset, mistakes cost nothing beyond a wasted few minutes. Staging (sometimes called “preview” or “test”) is a separate, deployed copy of the application, as close to production as practical, used to verify a change actually works before it reaches real users. Production is the real, live application, real users, real data, real consequences, this is the environment every other environment exists to protect.

What Actually Differs

Concretely, across these three environments: the database (a local database in development, an entirely separate one in staging, the real one in production, never shared), log verbosity (detailed in development, quieter in production, Course 3’s pino log levels exist exactly for this), external services (a payment provider’s test mode in development and staging, the real one only in production), and secrets (every environment has its own, Lesson 3 covers this specifically). A bug in staging should be expected and cheap, the same bug in production is a real incident.

What Should Never Differ

The application’s actual logic, its routes, its validation rules, its authentication and authorization checks, should be identical in every environment. If a security check only runs in production, staging can’t actually verify it works, the whole point of staging is testing the real behavior before it’s live, environment differences belong in configuration (this module), never in the application’s actual behavior.

Why This Course Starts Here

Every module after this one, containers, CI/CD, deployment, caching, scaling, assumes an application that already knows how to behave correctly and safely in more than one environment. Getting configuration right first is what makes every later module possible without introducing a new class of bug, a staging secret leaking into version control, or a production database URL pointed at from a local development machine by mistake.

Try It

1. List, in your own words, three things that should differ between your development setup and a production deployment of the same application.
2. List two things that should never differ between them, and explain why a difference there would be a bug, not a feature.
3. Think of an application you’ve used that clearly had a broken staging or preview environment, describe what gave it away.

Recap

• Development, staging, and production are distinct environments, each with a different purpose, different data, and different consequences for a mistake.
• Configuration (databases, log levels, secrets, external services) should differ between environments, application logic should not.
• This module’s later lessons build the actual mechanism for that distinction, NODE_ENV, per-environment configuration, and environment-specific secrets.

Next lesson: NODE_ENV, and building configuration that actually adapts to it.