[GH-ISSUE #5639] Change Hostname via CLI (After Registration) #11575

Open
opened 2026-08-05 01:30:04 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @PowershellScripter on GitHub (Mar 20, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5639

**Preface - If this is not seen as a beneficial feature request, I still have ways to work around it. For automation scenarios, this would be a benefit.

Is your feature request related to a problem? Please describe.
Not really a problem, just minor inconvenience as it relates to initial vs permanent connection settings.

Describe the solution you'd like
When registering a peer, there are instances where registering a temporary name is necessary in order to not overlap with peers that may have the same name. Once verified there is no overlap with the name wanting to permanently use, instead of deregistering the peer, just being able to update the custom peer name would be nice. This is for automation scenarios where manual checking of the control plane is not relevant.

Describe alternatives you've considered
The most obvious is to deregister the node and register with new peer name

Additional context
To give a better understanding as to how this may be a valuable feature, this is the example I use in my environment.

We have a custom windows image that we deploy to several of our locations and have employees that load our equipment with the image on site.
They put in the name of what the domain system would be and that name is used to register the netbird vpn as well. But, sometimes there is a conflict if the name used is mistyped or already exists in the domain or peer list. So, the idea is to create the initial connection with netbird using a randomized name (our automation would create this name), then having the automation check the domain to see if the "wanted" name provided is an object that pre-exists in the domain. If it does, the automation would throw an error and stop the automation. But, if it doesnt, instead of deregistering and re-registering the peer with the "wanted" name, a cli command to update the --hostname {{wanted name}} would allow for the displayed name to be updated and also create less opportunity for the connection to fail during de/re-registration. I imagine this would also create less overhead with a disconnect and reconnect of the handshakes since it would just be updating peer information for the already established peer connection.

Originally created by @PowershellScripter on GitHub (Mar 20, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5639 **Preface - If this is not seen as a beneficial feature request, I still have ways to work around it. For automation scenarios, this would be a benefit. **Is your feature request related to a problem? Please describe.** Not really a problem, just minor inconvenience as it relates to initial vs permanent connection settings. **Describe the solution you'd like** When registering a peer, there are instances where registering a temporary name is necessary in order to not overlap with peers that may have the same name. Once verified there is no overlap with the name wanting to permanently use, instead of deregistering the peer, just being able to update the custom peer name would be nice. This is for automation scenarios where manual checking of the control plane is not relevant. **Describe alternatives you've considered** The most obvious is to deregister the node and register with new peer name **Additional context** To give a better understanding as to how this may be a valuable feature, this is the example I use in my environment. We have a custom windows image that we deploy to several of our locations and have employees that load our equipment with the image on site. They put in the name of what the domain system would be and that name is used to register the netbird vpn as well. But, sometimes there is a conflict if the name used is mistyped or already exists in the domain or peer list. So, the idea is to create the initial connection with netbird using a randomized name (our automation would create this name), then having the automation check the domain to see if the "wanted" name provided is an object that pre-exists in the domain. If it does, the automation would throw an error and stop the automation. But, if it doesnt, instead of deregistering and re-registering the peer with the "wanted" name, a cli command to update the --hostname {{wanted name}} would allow for the displayed name to be updated and also create less opportunity for the connection to fail during de/re-registration. I imagine this would also create less overhead with a disconnect and reconnect of the handshakes since it would just be updating peer information for the already established peer connection.
saavagebueno added the feature-request label 2026-08-05 01:30:04 -04:00
Author
Owner

@PowershellScripter commented on GitHub (Apr 8, 2026):

Is this something that would be considered on the roadmap or only allowed via the API?

<!-- gh-comment-id:4209028377 --> @PowershellScripter commented on GitHub (Apr 8, 2026): Is this something that would be considered on the roadmap or only allowed via the API?
Author
Owner

@PowershellScripter commented on GitHub (Apr 29, 2026):

There were discussions of this being potentially added as a group based ACL permission feature. Any word on if this was decided or not?

<!-- gh-comment-id:4346656806 --> @PowershellScripter commented on GitHub (Apr 29, 2026): There were discussions of this being potentially added as a group based ACL permission feature. Any word on if this was decided or not?
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11575