> 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/core-concepts.md).

# Core concepts

### Resources

`bundle.resources` lists the resources that belong to the Bundle. Each resource entry needs an `id` so other entries can reference it.

```yaml
bundle:
  resources:
    - id: sleep-worker
      file: tests/worker/sleep-worker/worker.yaml
```

Use `file` when the Resource is defined in a separate manifest. This keeps each Resource reusable and easier to review.

### Dependencies

`dependencies` defines the resource IDs that must be processed before the current resource.

```yaml
bundle:
  resources:
    - id: verify-sleep-worker
      file: tests/worker/sleep-worker/verify-workflow.yaml
      dependencies:
        - sleep-worker
```

Dependencies create the Bundle DAG. A verification Workflow, for example, should depend on the Worker or Service it verifies.

### Dependency conditions

`dependencyConditions` controls when a dependent Resource is ready. Conditions can check the dependent Resource status, runtime state, or both.

```yaml
bundle:
  resources:
    - 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"
```

In this example, the verification Workflow is applied only after `sleep-worker` is active and its runtime contains `running`.

### Workspace placement

Use `workspace` on a Bundle resource entry when the referenced Resource must be created in a specific workspace.

```yaml
bundle:
  resources:
    - id: worker-in-sandbox
      workspace: sandbox
      file: tests/worker/sleep-worker/worker.yaml
```

Workspace-level resources, such as Workers, Workflows, Services, and Secrets, can be placed in workspaces. Instance-level resources are not scoped to a workspace.

### Inline specifications

Use `spec` when you want to define a Resource inline in the Bundle instead of referencing a file.

```yaml
bundle:
  resources:
    - id: inline-worker
      spec:
        version: v2alpha
        name: sleep-worker
        type: worker
        spec:
          compute: runnable-default
          replicas: 1
          executionMode: default
          stack: container
          stackSpec:
            image: docker.io/library/alpine:3.20
            command:
              - sh
            arguments:
              - -c
              - "while true; do echo heartbeat; sleep 30; done"
```

For most production bundles, separate files are easier to maintain than large inline resource definitions.

### Schedule, properties, and management user

Bundles can also include optional sections for scheduled create/delete operations, workspace creation, custom properties, and management user context.

```yaml
bundle:
  schedule:
    initialState: create
    timezone: Asia/Kolkata
    create:
      - cron: "5 0 24 1 *"
    delete:
      - cron: "25 0 24 1 *"
  workspaces:
    - name: bundlespace
      description: "Workspace for bundled resources"
      tags:
        - bundle
      labels:
        purpose: testing
      layer: user
  properties:
    purpose: integration-test
  manageAsUser: iamgroot
```

Use these sections only when the Bundle needs them. Simple Bundles often contain only `bundle.resources`.


---

# 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/core-concepts.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.