> 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/build/stage-3-publish/configure-product-deployment.md).

# Configure product deployment

Configuration is the preparation step. In this step, you verify that the required DataOS resources exist, prepare the repository, create the Git-sync secret, and define the two deployment files: `config.yaml` and `deploy.yaml`.

***

## What you will configure

Before deployment, you need:

| Requirement      | Purpose                                                                 |
| ---------------- | ----------------------------------------------------------------------- |
| DataOS CLI       | Used later to apply deployment definitions and check deployment status. |
| Depot            | Provides the connection to the warehouse or engine.                     |
| Engine stack     | Defines the execution engine used by Vulcan.                            |
| Compute resource | Provides runtime compute for Vulcan workflows.                          |
| Git repository   | Stores the Vulcan project files.                                        |
| Git-sync secret  | Lets DataOS sync the repository.                                        |
| `config.yaml`    | Defines Vulcan project configuration.                                   |
| `deploy.yaml`    | Defines the DataOS Vulcan resource.                                     |

{% stepper %}
{% step %}

## Verify DataOS CLI access

Confirm that the DataOS CLI is installed and that you can log in.

```bash
dataos-ctl login
dataos-ctl version
```

You should be able to authenticate successfully before deploying any resource.
{% endstep %}

{% step %}

## Verify the Depot

A Depot is required so Vulcan can connect to the data warehouse or engine.

List available depots:

```bash
dataos-ctl resource -t depot get -a
```

Verify the Depot you plan to use:

```bash
dataos-ctl resource -t depot get -n <depot-name> -a
```

Confirm that the Depot has read/write access to the target schema or database.

Example Depot reference:

```yaml
dataos://<depot-name>?purpose=rw
```

{% endstep %}

{% step %}

## Verify the engine stack

An engine stack defines the execution environment for Vulcan operations.

List available stacks:

```bash
dataos-ctl resource -t stack get -a
```

Supported engine examples:

* `snowflake`
* `postgres`
* `trino`
* `lakehouse`

Choose the engine that matches where your models will run.
{% endstep %}

{% step %}

## Verify compute resources

A compute resource provides the runtime environment for Vulcan workflows.

List available compute resources:

```bash
dataos-ctl resource -t compute get -a
```

Example compute resources:

* `cyclone-compute`
* `minerva-compute`
* Custom compute clusters

Use the compute resource approved for your environment and workload.
{% endstep %}

{% step %}

## Prepare the project repository

Your Vulcan project must be stored in a Git repository with the following sample structure:

```
my-vulcan-project/
├── config.yaml
├── usage.yaml
├── audits/
├── dq/
├── macros/
├── models/
│   ├── full_model.sql
│   ├── incremental_model.sql
│   ├── seed_model.sql
│   ├── metrics/
│   │   └── event_activity.yml
│   └── semantics/
│       └── incremental_model.yml
├── seeds/
└── tests/

```

Push the project to the Git branch that DataOS will sync during deployment.
{% endstep %}

{% step %}

## Create the Git-sync secret

If your repository is private, create a Git-sync secret.

```bash
dataos-ctl resource apply -f git-sync-secret.yaml
```

Example:

```yaml
name: git-sync
version: v2alpha
type: secret
workspace: system
layer: user
description: "Secret for git-sync authentication"
secret:
  type: key-value
  data:
    GITSYNC_USERNAME: "<your-git-username>"
    GITSYNC_PASSWORD: "<your-git-token-or-password>"
```

{% hint style="info" %}
Replace the placeholders with your Git credentials or access token. Do not commit real credentials to the repository.
{% endhint %}
{% endstep %}

{% step %}

## Configure `config.yaml`

The `config.yaml` file contains Vulcan project settings.

Location:

```
<project-root>/config.yaml
```

Use it to define:

* Product name and display name
* Product description
* Catalog metadata
* Version
* Alignment
* Tags and glossary terms
* Domain and use cases
* Model defaults
* Gateway configuration
* Notification targets
* Owners

Example:

{% code overflow="wrap" %}

```yaml
vde: false
name: orders-analytics
display_name: Orders Analytics Platform
description: Governed e-commerce order analytics for revenue, customer segmentation, product performance, fulfillment, and sales funnel monitoring on PostgreSQL.
discoverable: true
version: 0.1.2
alignment: source_aligned

tags:
  - e-commerce
  - orders
  - sales-analytics
  - customer-analytics
  - postgres

terms:
  - glossary.data_product
  - glossary.orders
  - glossary.revenue
  - glossary.customer_segmentation

domain: sales_operations

linter:
  enabled: true
  warn_rules:
    - RequireGrainForAllModels
    - RequireOwnerForAllModels
    - RequireAssertionsOrAuditsForAllModels
    - RequireDqForAnalyticsModels
    - RequireGeneratedBronzeSources
    - preferassertions
    - nomissingaudits

model_defaults:
  dialect: postgres
  start: '2025-01-01'
  cron: '*/15 * * * *'

before_all:
  - CREATE SCHEMA IF NOT EXISTS bronze;
  - CREATE SCHEMA IF NOT EXISTS silver;
  - CREATE SCHEMA IF NOT EXISTS gold;
  - GRANT USAGE ON SCHEMA bronze, silver, gold TO db_owner;
  - ALTER DEFAULT PRIVILEGES IN SCHEMA bronze GRANT SELECT ON TABLES TO db_owner;
  - ALTER DEFAULT PRIVILEGES IN SCHEMA silver GRANT SELECT ON TABLES TO db_owner;
  - ALTER DEFAULT PRIVILEGES IN SCHEMA gold GRANT SELECT ON TABLES TO db_owner;
  - SET statement_timeout = '120s';
  - SET lock_timeout = '30s';
  - SET idle_in_transaction_session_timeout = '60s';
after_all:
  - ANALYZE bronze.orders;
  - ANALYZE bronze.order_items;
  - ANALYZE silver.fct_daily_sales;
  - RESET statement_timeout;
  - RESET lock_timeout;
  - RESET idle_in_transaction_session_timeout;

gateways:
  default:
    connection:
      type: depot
      address: dataos://postgresDepot
      
notification_targets:
  - type: console
    notify_on:
      - apply_start
      - apply_end
      - apply_failure
      - run_start
      - run_end
      - run_failure
      - audit_failure
      - check_start
      - check_end
      - check_failure
      - migration_start
      - migration_end
      - migration_failure
      - plan_change

users:
  - username: johndoetmdcio
    email: john.doe@tmdc.io
    type: OWNER
  - username: data_team
    email: data-team@tmdc.io
    type: CONTRIBUTOR

variables:
  environment: local
  bronze_schema: bronze
  silver_schema: silver
  gold_schema: gold
  min_customer_count: 10
  min_order_count: 20

```

{% endcode %}

{% hint style="info" %}
`DATAOS_TENANT_ID` should be provided through the environment or `.env`, not as a YAML key.
{% endhint %}
{% endstep %}

{% step %}

## Configure `deploy.yaml`

The `deploy.yaml` file defines the DataOS Vulcan resource.

Location:

```
<project-root>/deploy.yaml
```

You can create it manually or generate a starter manifest:

```bash
vulcan create_deploy_yaml
```

Example:

{% code overflow="wrap" %}

```yaml
version: v1alpha
type: vulcan
name: orders-analytics
tags:
  - order-analytics
  - sales-operations
  - postgres
spec:
  runAsUser: "johndoetmdcio"
  compute: pacific
  engine: postgres
  repo:
    url: https://bitbucket.org/rubik_/vulcan-examples
    syncFlags:
      - '--ref=shreya-examples'
      - '--submodules=off'
    baseDir: vulcan-examples/engines/postgres/new/orders-analytics
    secretId: product-sandbox:git-sync
  depots:
    - dataos://postgresDepot?purpose=rw
  workflow:
    schedule:
      crons:
        - '*/15 * * * *'
      endOn: '2027-01-01T00:00:00-00:00'
      timezone: 'US/Pacific'
      concurrencyPolicy: Forbid
    logLevel: INFO
    resource:
      request:
        cpu: "200m"
        memory: "512Mi"
      limit:
        cpu: "1000m"
        memory: "1Gi"

    plan:
      command:
        - vulcan
      arguments:
        - --log-to-stdout
        - plan
        - --auto-apply
    run:
      command:
        - vulcan
      arguments:
        - --log-to-stdout
        - run
  api:
    replicas: 2
    logLevel: INFO
    resource:
      request:
        cpu: "200m"
        memory: "512Mi"
      limit:
        cpu: "4000m"
        memory: "3Gi"

```

{% endcode %}
{% endstep %}
{% endstepper %}


---

# 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/build/stage-3-publish/configure-product-deployment.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.