# Large scale deployment of beats through Central Management **URL:** \ **Category:** Beats\ **Tags:** fleet\ **Created:** [January 25, 2019, 8:06pm UTC](https://discuss.elastic.co/t/large-scale-deployment-of-beats-through-central-management/165822 "2019-01-25T20:06:07Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [January 25, 2019, 8:06pm UTC](https://discuss.elastic.co/t/large-scale-deployment-of-beats-through-central-management/165822/1 "2019-01-25T20:06:08Z")
After testing out beats central management for a few days I wondering how you scale this feature. From my understanding when you enroll a beat its on a one to one ratio. A user clicks on Enroll Beats, gets a link/token/command and then runs the beat with the autogenerated command. With this setup it seems like theres no efficient way to deploy central manager to 100's or 1000's of beats since each UUID is specific to the beat it was run on, unless you can use the same UUID on multiple beats. If I'm misunderstanding the use of CM feel free to let me know. Appreciate the guidance. ---
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [January 25, 2019, 8:18pm UTC](https://discuss.elastic.co/t/large-scale-deployment-of-beats-through-central-management/165822/2 "2019-01-25T20:18:47Z")
Seems like my answer was right here unless anyone else has something to add to this. [https://www.elastic.co/guide/en/beats/metricbeat/current/enroll-beats.html](https://www.elastic.co/guide/en/beats/metricbeat/current/enroll-beats.html) ### Username and password-based enrollment[edit](https://github.com/elastic/beats/edit/6.5/libbeat/docs/shared-central-management.asciidoc) You can also enroll by specifying a username and password. This is the recommended way for scripted deploys: metricbeat enroll KIBANA\_URL --username USER --password METHOD [--force] **`--username USER`** The username to use for password-based enrollment. The default username is `elastic` . **`--password METHOD`** The method to use for getting the password. Available options are: - `env:VAR_NAME` gets the password from the environment variable `VAR_NAME` - `stdin` prompts the user for a password. This is the default. **`--force`** Overwrites the current settings without asking for confirmation. ---
**Author:** ![danielsnelling](https://avatars.discourse-cdn.com/v4/letter/d/76d3ee/32.png) [@danielsnelling](https://discuss.elastic.co/u/danielsnelling)\ **Post date:** [October 16, 2019, 9:43pm UTC](https://discuss.elastic.co/t/large-scale-deployment-of-beats-through-central-management/165822/3 "2019-10-16T21:43:07Z")
Are the username/password creds saved on each Beat for it to continually retrieve management from Kibana? Or are they just used to generate a unique token? Reusing credentials doesn't seem like a good way of controlling hundreds and thousands of Beats, considering other credentials (like to output to Elasticsearch) are potentially able to be retrieved from Central Management. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 4, 2022, 6:52am UTC](https://discuss.elastic.co/t/large-scale-deployment-of-beats-through-central-management/165822/4 "2022-11-04T06:52:34Z")