# Deployment considerations for beats containing dashboards

**URL:** <https://discuss.elastic.co/t/deployment-considerations-for-beats-containing-dashboards/289021>\
**Category:** Beats\
**Tags:** filebeat, packetbeat, metricbeat\
**Created:** [November 11, 2021, 9:49pm UTC](https://discuss.elastic.co/t/deployment-considerations-for-beats-containing-dashboards/289021 "2021-11-11T21:49:39Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![jhettich](https://avatars.discourse-cdn.com/v4/letter/j/f6c823/32.png) [@jhettich](https://discuss.elastic.co/u/jhettich)\
**Post date:** [November 11, 2021, 9:49pm UTC](https://discuss.elastic.co/t/deployment-considerations-for-beats-containing-dashboards/289021/1 "2021-11-11T21:49:39Z")

</div>

Beats often contain dashboards, which can be imported into Kibana by running the "setup" command. However, beats are typically data shippers that you install as agents _on your servers_.  
Since, from a deployment perspective, the beat is installed and run near the "edge" of your network, whereas Kibana and Elasticsearch are "central" resources, why does it make sense to package Kibana dashboards with a beat? For example, if a beat is installed on a remote server to be used as a data shipper, does an admin also have to separately install it on or near the Kibana server in order to load the associated dashboards?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 9, 2021, 11:50pm UTC](https://discuss.elastic.co/t/deployment-considerations-for-beats-containing-dashboards/289021/2 "2021-12-09T23:50:28Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.