Production is the live environment where software runs and serves real users. It is distinguished from development (a developer's local machine), staging (a production-like environment used for testing before release), and CI (the automated build environment).

The term matters because production has properties that other environments do not: real user data, unpredictable load patterns, historical state that cannot be reset, and consequences when something breaks. A bug in development costs nothing. A bug in production costs user trust, data integrity, or revenue.

A typical environment progression:

development → staging → production

Development is where code is written and tested locally. Staging mirrors production configuration as closely as possible and is used to validate a release before it reaches users. Production is the final destination.

Some organisations add more stages (QA, UAT, pre-production) or maintain separate production environments by region. The key principle is that each stage should be as close to production as possible, otherwise tests in staging do not predict behaviour in production.

The most common failure mode is a discrepancy between environments. A bug that cannot be reproduced locally but happens in production is usually caused by a difference in configuration, data, OS version, or dependency versions. DevOps practices — especially infrastructure as code and identical environment definitions — reduce these discrepancies.

Changes to production should go through a CI/CD pipeline, not manual deployments. Direct access to modify production databases or run arbitrary code should be restricted and logged. Feature flags and canary releases are tools for limiting the blast radius of a bad deployment. Observability (logs, metrics, alerts) is what makes it possible to detect a problem in production quickly.