Production Environment (Prod)

By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site

The live system that real users and real data depend on, as opposed to a test copy.

Code usually moves from development (your machine) to staging (a copy of production for final checks) to production. The same build should run in each, with only configuration such as the database address changing, so staging can catch what would break prod. A common beginner mistake is testing with production data or credentials; each environment needs its own secrets.

The intuition

Production, or prod, is the version of a system that real people and real money depend on. The same application usually exists in several copies: development on each engineer's machine, a shared test or staging copy that mirrors production as closely as possible, and production itself. Only the last one matters to clients, regulators and the P&L. The others exist so that mistakes are made somewhere harmless first. The word carries weight in a data team for that reason: a bug in dev costs an afternoon; a bug in prod can misprice a book or send a wrong statement.

The principle that makes the chain work is that the build does not change between environments, only the configuration. The same code and the same dependencies that passed in staging are promoted to production, with environment variables pointing at a different database, a different market-data endpoint and different secrets. If staging ran one version and production another, staging's green tests would prove nothing. Infrastructure follows the same rule where possible: staging is a smaller, isolated replica, not a laptop pretending to be a server.

Production also has rules the other environments do not. Access is restricted and logged, changes go through review and often a change window, secrets are issued by a vault rather than typed by hand, and anything that reads from or writes to prod is monitored. The classic failures are not exotic: a script developed against the production database because the test copy was stale; a credential for prod pasted into a notebook; a deployment on a Friday evening with nobody watching. The discipline exists because prod is the only environment where undo is expensive.

Example

import os

env = os.environ.get("ENV", "development")
db_url = os.environ["DATABASE_URL"]  # required: a different database in each environment, KeyError if unset
print(f"Running in {env}")

Promoting a change to the nightly pricing job from a laptop to production

A quant changes how the nightly pricing job handles a new bond type. On her laptop, the development environment, ENV=development and DATABASE_URL points at a local PostgreSQL seeded with a few hundred synthetic positions. She runs the job, the unit tests pass, and she opens a pull request.
Continuous integration builds the application once, runs the tests and produces an immutable artefact: a container image tagged pricing-job:1.14.0. That exact image is what every later environment will run; nothing is rebuilt per environment.
Staging: the pipeline deploys 1.14.0 to the staging cluster, where ENV=staging and DATABASE_URL points at a sanitised copy of last week's production positions, with client names replaced. The job runs against 48,000 real-shaped positions. It fails: one legacy instrument has a null coupon field the synthetic data never contained. This is exactly what staging is for.
Fix, rebuild as 1.14.1, re-run staging: green. The pricing numbers are diffed against the previous version's output; 212 positions changed, all of the new bond type, none of the rest. A reviewer signs off.
Production: the release manager promotes 1.14.1 during the change window at 18:30, after market close. The deployment pulls the same image; only the environment variables differ: ENV=production, DATABASE_URL from the vault, the live market-data endpoint. The 02:00 run completes, and the monitoring dashboard shows run time and row counts in line with yesterday.
What goes wrong elsewhere: a colleague, under time pressure, tests his own change by pointing his laptop at the production DATABASE_URL copied from the vault. His script has a bug that updates prices in place. The morning P&L is wrong for two desks and the fix is a restore from backup. The post-mortem introduces separate read-only prod credentials and a rule that laptops never hold production secrets.

One build, promoted unchanged through dev, staging and prod with only configuration differing, is what makes a green staging run mean something, and keeping production credentials off laptops is what keeps prod safe from good intentions.

Common pitfalls

Testing against production data or credentials because the staging copy is stale: the fix is to refresh staging, not to borrow prod.
Rebuilding the application for each environment: a build that differs from the one tested in staging has not been tested.
Hard-coding environment-specific values in code, so a change to the database address needs a code change and a redeploy of everything.
Granting broad write access to production to anyone who might need it: most engineers need read-only access, and the few writes should go through the deployment pipeline.
Deploying without a rollback path or at a bad time: a nightly pricing job released at 17:55 on a Friday with no one on call turns a small bug into a weekend.

Frequently asked questions

What does prod mean in IT?

Prod is short for the production environment: the live, deployed version of a system that real users and real data rely on, as opposed to development and staging copies used for building and testing. Saying something is in prod means it affects clients, reports or money, which is why changes to it are reviewed, scheduled and monitored.

What is the difference between staging and production?

Staging is a replica of production used for final testing: same build, similar infrastructure and realistic (usually anonymised) data, but no real users depend on it. Production serves real users. The point of staging is to catch what unit tests and a developer's laptop cannot, such as data shapes, integrations and performance, before the same build is promoted unchanged to prod.

Why should developers not have access to production data?

Because production holds real client and financial data subject to confidentiality and regulation, and because a mistake there is costly to undo. Developers work with synthetic or anonymised copies in dev and staging. Where production access is genuinely needed, it is read-only, time-limited and logged, and credentials come from a vault rather than living on laptops.

How does code get from development to production?

Through a pipeline: a change is reviewed, built once into an artefact such as a container image, tested automatically, deployed to staging for integration checks, and then promoted to production, often in a scheduled window with monitoring and a rollback plan. Only configuration, read from environment variables or a vault, changes between environments; the artefact does not.