> 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/concepts/resources/depot/configurations.md).

# Manifest configurations

## Structure of Depot manifest file

{% code title="Depot YAML file" %}

```yaml
name: ${{name}}
version: v2alpha
type: depot
tags:
  - ${{tag-1}} # optional
  - ${{tag-2}} # optional
owner: ${{owner-id}} # optional
layer: user
description: ${{description}} # optional
spec:
  type: ${{source-type}}
  spec:
    # source-specific attributes go here  
  secrets:
    - id: "${{tenant-id}}:${{secret-name}}"
      purpose: scan
    - id: "${{tenant-id}}:${{secret-name}}"
      purpose: query
    - id: "${{tenant-id}}:${{secret-name}}"
      purpose: rw
```

{% endcode %}

## Attributes configuration

### **`name`**

**Description:** Declare a name for the Depot.

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**                                                                                      |
| ------------- | --------------- | ----------------- | ------------------------------------------------------------------------------------------------------- |
| string        | mandatory       | none              | Resource name must be less than `48` characters and conform to the following regex: `[a-z]([a-z0-9]*)?` |

**Example usage:**

```yaml
name: abfssdepot
```

### **`version`**

**Description:** The version of the Resource.

| **Data Type** | **Requirement** | **Default Value** | **Possible Value** |
| ------------- | --------------- | ----------------- | ------------------ |
| string        | mandatory       | none              | v2alpha            |

**Example usage:**

```yaml
version: v2alpha
```

### **`type`**

**Description:** Provide the value for the Resource type.

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**                                       |
| ------------- | --------------- | ----------------- | -------------------------------------------------------- |
| string        | mandatory       | none              | depot (in this case), secret, service, stack or workflow |

**Example usage:**

```yaml
type: depot
```

### **`tags`**

**Description:** Assign tags to the Resource-instance

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**                         |
| ------------- | --------------- | ----------------- | ------------------------------------------ |
| list          | optional        | none              | any string; special characters are allowed |

**Example usage:**

```yaml
tags:
  - "data connection"
  - "snowflake depot"
```

### **`description`**

**Description:** Assign description to Resource

| **Data Type** | **Requirement** | **Default Value** | **Possible Value** |
| ------------- | --------------- | ----------------- | ------------------ |
| string        | optional        | none              | any string         |

**Additional information:** the description can be within quotes or without.

{% hint style="warning" %}
YAML supports 'scalars' such as strings, numbers, booleans, and null. A scalar value can be unquoted, within single quotes (') or double quotes ("). When the scalar contains a special character, the value must be declared within quotes.
{% endhint %}

**Example usage:**

```yaml
description: "This is a sample description of a Resource"  
```

### **`owner`**

**Description:** Identification of the user

| **Data Type** | **Requirement** | **Default Value**                    | **Possible Value**       |
| ------------- | --------------- | ------------------------------------ | ------------------------ |
| string        | optional        | id of the user applying the Resource | any valid dataos user id |

**Additional information:** When no ID is provided, the system sets it to the ID of the user who applied the Resource on the DataOS CLI. Use the updated user-id format in examples, such as `iamgrootio` or `johndoeio`.

**Example usage:**

```yaml
owner: iamgrootio
```

### **`layer`**

**Description:** Declare the name of the layer in which the Resource is going to be deployed

| **Data Type** | **Requirement** | **Default Value** | **Possible Value** |
| ------------- | --------------- | ----------------- | ------------------ |
| string        | optional        | user              | user/system        |

**Additional information:** From a user's perspective, the operating system works at two levels: the user layer and the system layer. This is a logical separation to help you understand how the system works.

**Example usage:**

```yaml
layer: user
```

## `spec`

**Description:** specifies the configuration for the Depot section

| **Data Type** | **Requirement** | **Default Value** | **Possible Value** |
| ------------- | --------------- | ----------------- | ------------------ |
| mapping       | mandatory       | none              | none               |

Example Usage:

```yaml
spec:
  {}
```

### **`type`**

**Description:** Specifies the source type of the Depot under `spec`

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**                                                                                                                                                |
| ------------- | --------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| string        | mandatory       | none              | `abfss`, `bigquery`, `elasticsearch`, `eventhub`, `gcs`, `jdbc`, `kafka`, `mongodb`, `mysql`, `opensearch`, `oracle`, `postgresql`, `redshift`, `s3`, `snowflake` |

Example Usage:

```yaml
spec:
  type: abfss
```

### **`description`**

**Description:** Provides a description for the source config under `spec`

| **Data Type** | **Requirement** | **Default Value** | **Possible Value** |
| ------------- | --------------- | ----------------- | ------------------ |
| string        | optional        | none              | any string         |

**Example Usage:**

```yaml
spec:
  description: Azure Blob Storage Depot
```

### **`source`**

**Description:** Maps the depot to the metadata source name in Metis. Running a scanner job on this depot will save the metadata in Metis DB under the specified 'source' name. If this key-value property is not mentioned, the metadata will surface under the depot name on Metis UI.

| **Data Type** | **Requirement** | **Default Value** | **Possible Value** |
| ------------- | --------------- | ----------------- | ------------------ |
| string        | optional        | depot name        | any string         |

Example Usage:

```yaml
spec:
  source: bigquerymetadata
```

### **`secrets`**

**Description:** Specifies the Secret reference(s) for the data source under `spec`.

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**          |
| ------------- | --------------- | ----------------- | --------------------------- |
| mapping       | optional        | none              | varies between data sources |

**Example Usage:**

```yaml
spec:
  secrets:
    - id: "${{tenant-id}}:${{secret-name}}"
      purpose: scan
    - id: "${{tenant-id}}:${{secret-name}}"
      purpose: query
    - id: "${{tenant-id}}:${{secret-name}}"
      purpose: rw
```

### **`secrets.id`**

**Description:** The `id` attribute specifies the tenant-qualified Secret reference (`<tenant>:<secret-name>`).

### **`secrets.purpose`**

**Description:** The `purpose` attribute labels the intended access usage for a Secret attached to the Depot. It acts as a friendly, unique identifier that lets DataOS resolve which Secret to use for a given operation without requiring callers to know Secret names or IDs directly.

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**    |
| ------------- | --------------- | ----------------- | --------------------- |
| string        | mandatory       | none              | `scan`, `query`, `rw` |

**How purpose labels work**

Each purpose label must be unique within a Depot. The Depot Service maintains the mapping between a purpose label and its Secret — the Secret itself does not carry the label. When a DataOS component needs credentials for a specific operation (for example, read/write access), it requests the Secret by purpose label from the Depot rather than by Secret name.

**Valid combinations**

Each purpose label appears only once in the Depot, even when multiple labels point to the same Secret:

```yaml
secrets:
  - id: "${{tenant-id}}:s1"
    purpose: db-read
  - id: "${{tenant-id}}:s1"
    purpose: db-write
  - id: "${{tenant-id}}:s2"
    purpose: api-access
  - id: "${{tenant-id}}:s3"
    purpose: storage-read
```

**Invalid combinations**

Duplicate purpose labels within the same Depot are not allowed, even if they reference different Secrets:

```yaml
secrets:
  - id: "${{tenant-id}}:s1"
    purpose: db-read
  - id: "${{tenant-id}}:s2"
    purpose: db-read  # invalid — duplicate purpose label
```

{% hint style="warning" %}
Defining the same purpose label twice in a Depot is invalid regardless of whether the two entries reference the same Secret or different Secrets.
{% endhint %}

### **`spec.spec`**

**Description:** Specifies source-specific attributes (for example host, bucket, nodes, database, etc.).

| **Data Type** | **Requirement** | **Default Value** | **Possible Value**          |
| ------------- | --------------- | ----------------- | --------------------------- |
| mapping       | mandatory       | none              | varies between data sources |

**Example Usage:**

```yaml
spec:
  type: abfss
  spec:
    account: ${{account-name}}
    container: ${{container-name}}
    relativePath: ${{relative-path}} # optional
    format: ${{format}} # optional
```


---

# 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/concepts/resources/depot/configurations.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.