> 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/references/dataos-resources/bundle.md).

# Bundle

A Bundle is a DataOS Resource that deploys a collection of Resources in one operation. Use a Bundle to package the resources that make up an application, test, or Data Product so they can be applied, verified, and deleted together.

As its name suggests, a Bundle groups resources into a flattened directed acyclic graph (DAG). Each resource in the Bundle is a node, and dependency rules define the order in which resources are created.

## Access requirements

Before you create or manage a Bundle, you must have the required tenant roles and permissions. If you do not have access, contact your DataOS administrator.

## Why use a Bundle

Use a Bundle when you need to:

* Deploy multiple related Resources in a single operation.
* Define dependencies between Resources.
* Wait for a Resource to become active or running before deploying the next Resource.
* Package verification Workflows with the Resources they validate.
* Keep deployment logic in source control for review and CI/CD.
* Delete a grouped set of Resources in a controlled order.

Common examples include a Worker with a verification Workflow, a Service with a Secret and verification Workflow, or a Data Product deployment that includes Depots, Secrets, Workflows, or Services.

## Manifest structure

A Bundle manifest uses the common Resource metadata fields and a `bundle` section that defines the resources to deploy.

{% tabs %}
{% tab title="Syntax" %}
{% code expandable="true" collapsedlinecount="12" %}

```yaml
version: v2alpha
name: ${{bundle-name}}
type: bundle
description: ${{description}}
tags:
  - ${{tag}}
bundle:
  resources:
    - id: ${{resource-id}}
      file: ${{resource-manifest-path}}
      dependencies:
        - ${{dependency-resource-id}}
      dependencyConditions:
        - resourceId: ${{dependency-resource-id}}
          status:
            is:
              - ${{expected-status}}
            contains:
              - ${{expected-status-fragment}}
          runtime:
            is:
              - ${{expected-runtime}}
            contains:
              - ${{expected-runtime-fragment}}
```

{% endcode %}
{% endtab %}

{% tab title="Example" %}
{% code expandable="true" collapsedlinecount="14" %}

```yaml
version: v2alpha
name: test-postgres-itest
type: bundle
description: |
  Postgres on dataplane: Volume → Postgres service (port 5432) → depot secret.
  Secret (POSTGRES_ITEST_DEPOT_SECRET_NAME) is reused by test-vulcan-dp-postgres (postgresdepot).
  Vulcan state-store connection secret is created by vulcan-connections (make infra).
tags:
  - test
  - infra
  - postgres
  - volume
bundle:
  resources:
    - id: postgres-volume
      file: tests/infra/postgres-itest/volume.yaml

    - id: postgres-service
      file: tests/infra/postgres-itest/postgres-service.yaml
      dependencies:
        - postgres-volume
      dependencyConditions:
        - resourceId: postgres-volume
          status:
            is:
              - active

    - id: postgres-itest-depot-secret
      file: tests/infra/postgres-itest/depot-secret.yaml
      dependencies:
        - postgres-service
      dependencyConditions:
        - resourceId: postgres-service
          status:
            is:
              - active
          runtime:
            contains:
              - "running"


```

{% endcode %}
{% endtab %}
{% endtabs %}

For resource graphs, dependencies, workspace placement, inline specs, and optional bundle settings, see [Core concepts](/references/dataos-resources/bundle/core-concepts.md).

## Example

### Deploy a Workflow with a Bundle

You can package a Workflow inside a Bundle. A **Bundle** is a wrapper that groups resources together.

A Bundle can include the following as part of the deployment:

* a **Workflow,** a **Service,** a **Worker**
* other resources like **Secrets**, **Depots**, and **Minerva cluster**

So the relationship is:

* **Bundle** manages resource packaging and deployment order
* **Workflow / Service / Worker** manages runtime behavior

Example:

{% code expandable="true" collapsedlinecount="10" %}

```yaml
version: v2alpha
name: workflow-bundle
type: bundle
description: Bundle for deploying a basic workflow
bundle:
  resources:
    - id: data-processing-job
      file: workflow.yaml
```

{% endcode %}

### Bundle-based orchestration

{% code expandable="true" collapsedlinecount="12" %}

```yaml
# Bundle that orchestrates multiple resource types
version: v2alpha
name: complete-data-platform
type: bundle
description:"Complete data platform with API, processing, and monitoring"
bundle:
resources:
    # Phase 1: Deploy supporting infrastructure
-id: customer-database
file: artifacts/depots/postgres/create-postgres-depot.yaml

-id: storage-volume
file: artifacts/volumes/data-storage-volume.yaml

    # Phase 2: Deploy processing services
-id: customer-api
file: artifacts/services/customer-api-service.yaml
dependencies:[customer-database]
dependencyConditions:
-resourceId: customer-database
status:{is:[active]}

    # Phase 3: Deploy batch processing
-id: nightly-etl
file: artifacts/workflows/customer-etl-workflow.yaml
dependencies:[customer-database, customer-api]
dependencyConditions:
-resourceId: customer-database
status:{is:[active]}
-resourceId: customer-api
status:{is:[active]}

    # Phase 4: Deploy continuous monitoring
-id: event-monitor
file: artifacts/workers/event-monitoring-worker.yaml
dependencies:[customer-api]
dependencyConditions:
-resourceId: customer-api
status:{is:[active]}
```

{% endcode %}

### Worker verification Bundle

This Bundle deploys a long-running Worker, then runs a Workflow to verify that the Worker is active and then runs a Workflow to verify that the Worker is active and running.

{% code expandable="true" collapsedlinecount="14" %}

```yaml
version: v2alpha
name: test-worker-sleep
type: bundle
description: "Integration test: deploy a minimal long-running worker (container stack) and verify pod runtime is running"
tags:
  - test
  - worker
  - container
bundle:
  resources:
    # Step 1: Deploy the sleep worker (single replica, container stack)
    - id: sleep-worker
      file: tests/worker/sleep-worker/worker.yaml

    # Step 2: Verify the worker via the Poros API once the pod is reported running
    - id: verify-sleep-worker
      file: tests/worker/sleep-worker/verify-workflow.yaml
      dependencies:
        - sleep-worker
      dependencyConditions:
        - resourceId: sleep-worker
          status:
            is:
              - active
          runtime:
            contains:
              - "running"
```

{% endcode %}

The first entry deploys the Worker. The second entry runs only after the Worker reports `active` status and a runtime state containing `running`.

## Apply and manage

Apply the Bundle:

```bash
dataos-ctl resource apply -f bundle.yaml
```

Check a Bundle:

```bash
dataos-ctl resource get -t bundle -n ${{bundle-name}} -d
```

List Bundles:

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

Delete the Bundle:

```bash
dataos-ctl resource delete -t bundle -n ${{bundle-name}}
```

Delete by identifier:

```bash
dataos-ctl resource delete -i "${{bundle-name}}|v2alpha|bundle"
```

Delete by manifest:

```bash
dataos-ctl resource delete -f bundle.yaml
```

{% hint style="warning" %}
Deleting a Bundle can trigger deletion of resources associated with the Bundle. Resource deletion follows the reverse dependency order so dependent resources are removed before the resources they depend on.
{% endhint %}

## Field reference

See [Field reference](/references/dataos-resources/bundle/field-reference.md) for the complete Bundle manifest field reference, including nested `bundle.resources` and `dependencyConditions` fields.


---

# 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/references/dataos-resources/bundle.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.