web dev//deploy//deployment environment

A deployment environment is one complete, separate place where a version of an application runs, with its own servers, its own data, its own credentials and its own external services. Most projects keep at least two, development and production, and often a preview or staging one between them, so that a change can be tried for real without touching what users depend on.

A deployment environment is one complete, separate place where a version of an application runs, with its own servers, its own data, its own credentials and its own external services. Most projects keep at least two, development and production, and often a preview or staging one between them, so that a change can be tried for real without touching what users depend on.

The separation is the whole point. A test that deletes 500 rows in the development database costs nothing; the same test pointed at production deletes customers. So each environment gets its own database, its own API keys, its own mail and payment accounts in test mode, and the code reads which ones to use from environment variables, identical names with different values.

1Local machinelocalhost, a dev database2Previewa branch deploy, the dev database3Productionthe main branch, the real database

Branches map to environments. On Vercel or Cloudflare Pages a push to any branch builds a preview deployment at its own URL, and a merge into the production branch deploys the real site; reviewing a change means opening its preview, never testing on production.

Structure travels between environments, data does not. Both databases must have the same tables and columns, so changes to the structure are written once as a schema migration and applied to each environment in turn, while each keeps its own rows (test users in one, real users in the other).

Everything that acts on the outside world must be split too. A cron job in preview that sends real email, or a queue worker reading the production queue, defeats the separation; background jobs, webhooks and scheduled tasks are wired per environment.

The dangerous paths are the crossings: a preview build holding the production database URL, a local script run with production keys. Good setups make those crossings impossible rather than merely discouraged, by never giving lower environments the production secrets.

An environment is defined by what it can damage.

Code is the same everywhere; data, credentials and side effects are what must never cross from one environment to the next.

How a change travels from a push to production is the CI/CD pipeline.