Deploy dashboard with asset bundle

Seunghyun — Tue, 03 Feb 2026 08:06:45 GMT

Hello, I have some questions regarding dashboard development using Asset Bundles.

I have been following the procedure for developing dashboards by referring to this page: Databricks CI/CD for Dashboard Developers.

Here is the workflow I followed:

Created and developed a dashboard in my own workspace, then published it.
Ran databricks bundle generate dashboard --existing-id <id> -p <profile_name> locally to add the bundle.
Validated it using databricks bundle validate.
Deployed it using databricks bundle deploy --target prod -p <profile_name>.

Following these steps results in two dashboards with the same name. While their paths are different—one defined in databricks.yml and the other in my personal workspace—having two dashboards is confusing and makes it unclear which one should be modified later.

My questions are:

Is there a way to maintain only a single dashboard while still deploying via Asset Bundles?
What is the correct process for modifying and redeploying a dashboard after the initial deployment?
What is the optimal workflow for dashboard development and deployment?

I’ve searched extensively but couldn't find much information, so I'm reaching out for help.

Re: Deploy dashboard with asset bundle

Shaymi15 — Wed, 04 Feb 2026 10:02:37 GMT

Hi @Seunghyun,

It depends on how you separate env - by workspace or catalog.

it it's by workspace, in prod you should have only one copy of the dashboard.

if it's by catalog, it's a bit trickier. you might want to delete the dev dashboard manually and make sure all updates go through the bundle deployed dashboard...

Using asset bundle presets can also help a lot

Re: Deploy dashboard with asset bundle

SteveOstrowski — Sun, 08 Mar 2026 07:39:00 GMT

Hi @Seunghyun,

This is a common workflow question when getting started with AI/BI Dashboard deployment through Databricks Asset Bundles. Here is a walkthrough of the recommended approach to maintain a single dashboard and handle ongoing modifications.

WHY YOU END UP WITH TWO DASHBOARDS

When you run "databricks bundle generate dashboard --existing-id <id>", the command downloads the dashboard definition (.lvdash.json) and creates a YAML resource configuration. When you then run "databricks bundle deploy", the bundle creates a new dashboard at the path specified in your databricks.yml (typically under the bundle's root_path in the workspace). The original dashboard you created manually in your personal workspace still exists, so you now have two copies.

HOW TO MAINTAIN A SINGLE DASHBOARD

Option 1: Use the original dashboard as the source, then remove it after bundle deployment

1. Create and develop your dashboard in your workspace as you normally would.
2. Run the generate command to pull it into your bundle:

databricks bundle generate dashboard --existing-id <dashboard-id> -p <profile>

3. Deploy the bundle to your target environment:

databricks bundle deploy --target prod -p <profile>

4. After confirming the bundle-deployed dashboard works correctly, delete the original manual dashboard from your personal workspace. Going forward, the bundle-managed version is the single source of truth.

Option 2: Use the --existing-path flag with bind (recommended)

When you generate the dashboard configuration, you can use the --bind flag, which associates the generated bundle resource with the existing dashboard in the workspace instead of creating a new one:

databricks bundle generate dashboard --existing-id <dashboard-id> --bind -p <profile>

This tells the bundle to manage the existing dashboard in place rather than creating a separate copy. On subsequent deploys, the bundle updates the same dashboard rather than creating a new one.

Option 3: Set parent_path explicitly

In your databricks.yml resource configuration, set the parent_path to control where the dashboard is deployed. If you want it to land in a shared folder (not your personal workspace), specify that:

resources:
dashboards:
my_dashboard:
display_name: "My Dashboard"
file_path: ../src/my_dashboard.lvdash.json
warehouse_id: ${var.warehouse_id}
parent_path: /Shared/dashboards

CORRECT PROCESS FOR MODIFYING AND REDEPLOYING

Once the dashboard is managed by your bundle, the recommended workflow for making changes is:

1. EDIT IN THE UI: Make changes to the dashboard directly in the Databricks workspace UI as usual.

2. SYNC CHANGES BACK TO YOUR BUNDLE: Pull those UI changes into your local bundle files using:

databricks bundle generate dashboard --existing-id <dashboard-id> --force -p <profile>

The --force flag overwrites the local .lvdash.json file with the latest version from the workspace.

3. CONTINUOUS SYNC (OPTIONAL): If you want real-time sync while editing, use the --watch flag:

databricks bundle generate dashboard --existing-id <dashboard-id> --watch -p <profile>

This continuously polls and updates your local .lvdash.json as you make changes in the UI.

4. COMMIT TO VERSION CONTROL: After syncing, commit the updated .lvdash.json and any YAML changes to your Git repository.

5. DEPLOY TO OTHER ENVIRONMENTS: Run bundle deploy to push the updated dashboard to staging or production:

databricks bundle deploy --target prod -p <profile>

If the remote version has drifted from your local copy, add the --force flag:

databricks bundle deploy --target prod --force -p <profile>

OPTIMAL WORKFLOW SUMMARY

1. Develop the dashboard in a dev workspace or personal folder.
2. Generate the bundle configuration once: databricks bundle generate dashboard --existing-id <id> --bind
3. Store the .lvdash.json and YAML config in Git.
4. For ongoing edits, modify the dashboard in the UI, then sync back with: databricks bundle generate dashboard --existing-id <id> --force
5. Commit changes to Git, run CI/CD, and deploy with: databricks bundle deploy --target prod
6. Use variables like ${var.warehouse_id} to parameterize environment-specific settings (warehouse IDs, data sources) across dev/staging/prod targets.

AVOIDING DUPLICATE DASHBOARDS WITH GIT SYNC

If your workspace has Git folder sync enabled, the .lvdash.json files in your repo may also be picked up as dashboards. To prevent duplicates, add a sync exclusion in your databricks.yml:

sync:
exclude:
- src/*.lvdash.json

DOCUMENTATION REFERENCES

- CI/CD for Dashboard Developers: https://docs.databricks.com/aws/en/dev-tools/ci-cd/best-practices#cicd-for-dashboard-developers
- Bundle CLI generate command: https://docs.databricks.com/en/dev-tools/cli/bundle-commands.html
- Dashboard resource configuration: https://docs.databricks.com/en/dev-tools/bundles/resources.html

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

topic Re: Deploy dashboard with asset bundle in Data Engineering

Deploy dashboard with asset bundle

Re: Deploy dashboard with asset bundle

Re: Deploy dashboard with asset bundle