> 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/deploy-data-product.md).

# Deploy data product

This guide starts after the deployment files are ready. The goal is simple: **apply the Vulcan resource, monitor deployment, and verify that the Data Product is running correctly**.

This section shows how to deploy the Orders Analytics Data Product and make it available for use across the organization.

## Before you start

Complete [**Configure product deployment**](/build/stage-3-publish/configure-product-deployment.md) before following this guide.

You should have:

* A valid `config.yaml`
* A valid `deploy.yaml`
* A repository branch that contains the Vulcan project
* A Git-sync secret for repository access
* A Depot with read/write access
* A valid engine stack
* A valid compute resource
* DataOS CLI access

{% stepper %}
{% step %}

## Apply the Vulcan resource

Apply the deployment manifest:

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

This deploys the Vulcan resource and starts the managed runtime components.
{% endstep %}

{% step %}

## Check deployment status

Check the Vulcan resource status:

```bash
dataos-ctl resource -t vulcan -n <data-product-name> get
```

Check logs:

```bash
dataos-ctl resource -t vulcan -n <data-product-name> logs
```

Use this step to confirm that the resource was created and the runtime components started.
{% endstep %}

{% step %}

## Understand Vulcan runtime components

A deployed Vulcan resource does not run as one single container. DataOS creates multiple runtime components.

| Runtime component | What it does                                                     |
| ----------------- | ---------------------------------------------------------------- |
| `plan`            | Prepares deployment changes and runs `vulcan plan --auto-apply`. |
| `run`             | Executes models using `vulcan run`, usually on a schedule.       |
| `api`             | Runs the long-running API service and exposes endpoints.         |

You may see more than three runtime entries because scheduled runs create new workflow pods, and the API service may include multiple containers or sidecars.
{% endstep %}

{% step %}

## Choose the right logs

Use the correct logs based on what you are investigating.

| What you are investigating                | Check this log       |
| ----------------------------------------- | -------------------- |
| Model execution results                   | `run` logs           |
| Planning, migration, or auto-apply issues | `plan` logs          |
| API availability or query issues          | `api` logs           |
| GraphQL issues                            | GraphQL sidecar logs |
| MySQL wire protocol issues                | MySQL sidecar logs   |
| {% endstep %}                             |                      |

{% step %}

## Fetch logs with CLI

Use the DataOS CLI to fetch logs from a specific component and container.

```bash
dataos-ctl resource -t Vulcan -n <resource-name> logs \
  --container-group <container-group> -c <container-name>
```

Common examples:

| What you need              | `--container-group`   | `-c`   |
| -------------------------- | --------------------- | ------ |
| Planning or migration logs | `<name>-plan-execute` | `main` |
| Model execution logs       | `<name>-run-execute`  | `main` |
| API service logs           | `<name>-api`          | `main` |
| GraphQL sidecar logs       | `<name>-api`          | `sc-1` |
| MySQL sidecar logs         | `<name>-api`          | `sc-2` |

Example:

```bash
dataos-ctl resource -t Vulcan -n orders-analytics logs \
  --container-group orders-analytics-run-execute -c main
```

{% endstep %}

{% step %}

## Spark engine note

When the gateway uses Spark, Vulcan’s `run` and `plan` pods act as the **Spark driver**. In this mode, Vulcan can create multiple containers related to Spark execution, including driver and executor-related containers.

Start troubleshooting from the **DataOS run logs** because they usually show whether the failure happened before or during Spark job submission. If the failure points to distributed execution, inspect the Spark driver container logs first, then move to the Spark UI and executor logs.

Use **DataOS run logs** for the following:

* Spark connection issues
* Authentication errors
* Version mismatches
* Scheduler exceptions
* Driver-side stack traces
* Failures during job planning or submission

Use the **Spark driver container logs** for:

* Vulcan execution errors on Spark
* Spark session creation failures
* Job submission failures
* Driver-side exceptions
* Errors before tasks are distributed to executors

Use the **Spark UI and executor logs** for:

* UDF failures
* Worker out-of-memory errors
* Shuffle fetch failures
* Executor-side task failures
* Stage or task retries
* Data skew or long-running tasks
  {% endstep %}

{% step %}

## Verify deployed models

Connect to the target warehouse and verify that the expected tables or views exist.

Example for Snowflake:

```sql
SHOW TABLES IN SCHEMA <database>.<schema>;

SELECT *
FROM <database>.<schema>.<table-name>
LIMIT 10;
```

Confirm:

* Tables or views are created.
* Row counts are expected.
* Key models are queryable.
* Incremental or scheduled models are updating as expected.
  {% endstep %}

{% step %}

## Verify the API

If the API is exposed, test the live endpoint.

```bash
curl --location 'https://<env-fqn>/vulcan/tenants/<tenant>/vulcan/<data-product-name>/livez' \
  --header 'Authorization: Bearer <your-token>'
```

A successful response confirms that the Vulcan API service is running.
{% endstep %}

{% step %}

## Verify discovery and product visibility

After deployment, confirm that the Data Product is visible in the expected discovery surface.

Check:

* Product appears in the Product discovery
* Product metadata is visible
* Owner and description are present
* Inputs and outputs are visible
* Quality and run signals are available
* Access paths are working

Example data product:

<figure><img src="/files/LaSgogPY8rBLV4F9ETZO" alt=""><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

## Common issues

| Issue                    | What to check                                               |
| ------------------------ | ----------------------------------------------------------- |
| Repository does not sync | Git URL, branch, `baseDir`, Git-sync secret                 |
| Depot connection fails   | Depot name, credentials, permissions, warehouse access      |
| Stack is not found       | Engine stack name and availability                          |
| Compute is not found     | Compute name and workspace                                  |
| Plan fails               | `config.yaml`, gateway, model defaults, migrations          |
| Run fails                | Model SQL, dependencies, permissions, engine logs           |
| API fails                | API resource allocation, service status, sidecar logs       |
| Models are missing       | Run status, model materialization, target schema            |
| Product is not visible   | Scanner, metadata registration, product spec, target tenant |
| Spark job fails          | Driver logs in DataOS, executor logs in Spark UI            |

## Summary

To deploy a configured Data Product:

```
Apply resource -> Check status -> Review logs -> Verify models -> Verify API -> Confirm discovery
```

Once deployment is complete, the Vulcan resource should be running in DataOS with `plan`, `run`, and `api` components available for monitoring and troubleshooting.


---

# 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/deploy-data-product.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.