> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/data-developer/deploy-and-promote.md).

# Deploy and promote across environments

Deploying is one thing; promoting a product from experimentation to production reliably is the operational discipline around it. How you promote depends on how your operator sliced Tenants (see [Tenants and blueprints](/operate/v1/dataos-operator/design-tenants.md)).

## How the deploy works

The mechanics live in Build: you generate a `deploy.yaml`, apply it, and verify the product is live. This page assumes that and focuses on the promotion path. For the deploy steps themselves, see [Git & deploy](https://v2.dataos.info/build/productize/git-and-deploy) in the Build guide.

## Promote with environment tenants

The common blueprint separates environments into their own Tenants (`dev`, `stg`, `prod`). Promotion is then a controlled progression of the *same* project across Tenants:

1. **Build and validate in dev.** Plan and run locally, then deploy to the dev Tenant. Confirm runs, quality checks, and the served APIs behave.
2. **Promote to staging** by deploying the same Git ref to the staging Tenant, pointed at staging data sources and Compute. Validate against production-like data and access.
3. **Promote to production** by deploying the same ref to the prod Tenant. Production is the source of truth; nothing reaches it that did not pass staging.

What changes between environments is configuration, not code: the Tenant, the Depots and Compute it points at, and the credentials, all resolved per Tenant. Keep the project identical and let the environment supply the connections.

## Operating practices

* **One source of truth.** Promote a specific, tagged Git ref forward; do not edit directly in a higher environment.
* **Same project, different config.** Parameterize connections so the same code runs in each Tenant; never fork per environment.
* **Promote on green.** A product moves up only when its plan, tests, and quality checks pass in the environment below.
* **Coordinate breaking changes.** A schema or grain change that reaches production affects consumers; sequence it with the guidance in [Operate your product](/operate/v1/data-developer/operate-your-product.md).
* **Record what is where.** Track which ref is deployed in each Tenant so you can reason about and roll back a release.

Once deployed, the job becomes keeping it healthy: [Operate your product](/operate/v1/data-developer/operate-your-product.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/operate/v1/data-developer/deploy-and-promote.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.