starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Feature request: Webhooks #553

New Issue
Open
opened 2025-12-29 02:19:56 +01:00 by adam · 13 comments
adam commented 2025-12-29 02:19:56 +01:00
Owner
Copy Link

Originally created by @noseshimself on GitHub (Sep 6, 2023).

Why

MagicDNS is not exactly doing what I really need without a lot of hacks on my DNS servers. In a number of cases it would be easier to just update a "real" name server or use a completely different mechanism.

Information could be scraped from logs but that's inefficient. A special peer could be crafted to serve as bridge to external tools but that seems to be the completely wrong direction.

Description

Please add a simple mechanism that will call an external tool

The path to the tool should be configurable (and calls should only be made if it has been configured) and should send "event" (e. g. "client is ready"/"client has closed the connection"), account, client name and IP address(es). The exit code of the subprocess can be safely ignored. It's not your problem.

Originally created by @noseshimself on GitHub (Sep 6, 2023). ## Why MagicDNS is not exactly doing what I really need without a lot of hacks on my DNS servers. In a number of cases it would be easier to just update a "real" name server or use a completely different mechanism. Information could be scraped from logs but that's inefficient. A special peer could be crafted to serve as bridge to external tools but that seems to be the completely wrong direction. ## Description Please add a simple mechanism that will call an external tool The path to the tool should be configurable (and calls should only be made if it has been configured) and should send "event" (e. g. "client is ready"/"client has closed the connection"), account, client name and IP address(es). The exit code of the subprocess can be safely ignored. It's not your problem.
adam added the enhancementhelp wantedno-stale-botneeds design doc labels 2025-12-29 02:19:56 +01:00
adam commented 2025-12-29 02:19:56 +01:00
Author
Owner
Copy Link

@kedare commented on GitHub (Sep 19, 2023):

Ideally this would also support url to be able to call a webhook and not run a program (kind of like the webhooks on tailscale.com)

@kedare commented on GitHub (Sep 19, 2023): Ideally this would also support url to be able to call a webhook and not run a program (kind of like the webhooks on tailscale.com)
adam commented 2025-12-29 02:19:57 +01:00
Author
Owner
Copy Link

@noseshimself commented on GitHub (Sep 19, 2023):

Ideally this would also support url to be able to call a webhook and not run a program (kind of like the webhooks on tailscale.com)

In a way you might have the better idea; a webhook (being a remote procedure call using http(s) will be a mechanism that would be applicable even if you did not have a shell (thank you, Apple, for trying to keep users away from using the devices they own) or want to avoid having to use curl.

@noseshimself commented on GitHub (Sep 19, 2023): > Ideally this would also support url to be able to call a webhook and not run a program (kind of like the webhooks on tailscale.com) In a way you might have the better idea; a webhook (being a remote procedure call using http(s) will be a mechanism that would be applicable even if you did not have a shell (thank you, Apple, for trying to keep users away from using the devices they own) or want to avoid having to use curl.
adam commented 2025-12-29 02:19:57 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 24, 2023):

I think that webhooks would be a neat feature, I do not think we want to open the can of worms that is executing things outside of the go binary.

We dont really have this on our roadmap, but if someone wants to write up a design suggestion, we would be more than happy to help review and come with feedback.

@kradalby commented on GitHub (Sep 24, 2023): I think that webhooks would be a neat feature, I do not think we want to open the can of worms that is executing things outside of the go binary. We dont really have this on our roadmap, but if someone wants to write up a design suggestion, we would be more than happy to help review and come with feedback.
adam commented 2025-12-29 02:19:57 +01:00
Author
Owner
Copy Link

@noseshimself commented on GitHub (Sep 25, 2023):

We dont really have this on our roadmap, but if someone wants to write up a design suggestion, we would be more than happy to help review and come with feedback.

I believe I put my immediate need in my original request: I need to remotely update a DNS server because MagicDNS is breaking things on my end. That's why I am interested in the events "link up" and "link down" (assuming that you will never reassign IP addresses on the fly while connections are active.

I can certainly see other useful events (e. g. "account added", "node added", or "deleted").

Personally I would leave parsing the stuff to the consumer and keep the configuration part on your side as simple as possible. One hook per consumer and you either provide whatever you want as JSON and drop it off in front of the feet of the consumer(s) or you put all data into the URI itself and the consumer has to take that apart.

The only one who is able to judge which is easiest to implement is you. If you need to know which events the users would like to see it might be best to enable discussions and put it there.

@noseshimself commented on GitHub (Sep 25, 2023): > We dont really have this on our roadmap, but if someone wants to write up a design suggestion, we would be more than happy to help review and come with feedback. I believe I put my immediate need in my original request: I need to remotely update a DNS server because MagicDNS is breaking things on my end. That's why I am interested in the events "link up" and "link down" (assuming that you will never reassign IP addresses on the fly while connections are active. I can certainly see other useful events (e. g. "account added", "node added", or "deleted"). Personally I would leave parsing the stuff to the consumer and keep the configuration part on your side as simple as possible. One hook per consumer and you either provide whatever you want as JSON and drop it off in front of the feet of the consumer(s) or you put all data into the URI itself and the consumer has to take that apart. The only one who is able to judge which is easiest to implement is you. If you need to know which events the users would like to see it might be best to enable discussions and put it there.
adam commented 2025-12-29 02:19:57 +01:00
Author
Owner
Copy Link

@tiredofit commented on GitHub (Nov 8, 2023):

This is a feature of Tailscale and seems to be very useful. I too have problems with MagicDNS and the concept of hooks on specific actions would be extremely beneficial.

Tailscale implementation: https://tailscale.com/blog/webhooks/

@tiredofit commented on GitHub (Nov 8, 2023): This is a feature of Tailscale and seems to be very useful. I too have problems with MagicDNS and the concept of hooks on specific actions would be extremely beneficial. Tailscale implementation: https://tailscale.com/blog/webhooks/
adam commented 2025-12-29 02:19:58 +01:00
Author
Owner
Copy Link

@noseshimself commented on GitHub (Nov 15, 2023):

This is a feature of Tailscale and seems to be very useful

It is extremely useful. By mirroring my mesh-names of machines into my general DNS domains I'm able to have systems behind "mesh routers" (yes, I installed tailscale on OPNSense) using these addresses, too.

@noseshimself commented on GitHub (Nov 15, 2023): > This is a feature of Tailscale and seems to be very useful It is extremely useful. By mirroring my mesh-names of machines into my general DNS domains I'm able to have systems behind "mesh routers" (yes, I installed tailscale on OPNSense) using these addresses, too.
adam commented 2025-12-29 02:19:58 +01:00
Author
Owner
Copy Link

@celevra commented on GitHub (Nov 26, 2023):

+1

@celevra commented on GitHub (Nov 26, 2023): +1
adam commented 2025-12-29 02:19:58 +01:00
Author
Owner
Copy Link

@tarasglek commented on GitHub (Dec 8, 2023):

In theory this could already be done by following the headscale log. It would be nice if headscale supported emitting events to something like NATS

@tarasglek commented on GitHub (Dec 8, 2023): In theory this could already be done by following the headscale log. It would be nice if headscale supported emitting events to something like NATS
adam commented 2025-12-29 02:19:58 +01:00
Author
Owner
Copy Link

@sosnik commented on GitHub (Jan 20, 2024):

Would also like to have events emitted, whether as webhooks or as another mechanism doesn't really matter to me.

In the meantime, a hacky solution might be to use something like headscale nodes list -o json on a timer to dump status information in a machine-readable state.

@sosnik commented on GitHub (Jan 20, 2024): Would also like to have events emitted, whether as webhooks or as another mechanism doesn't really matter to me. In the meantime, a hacky solution might be to use something like `headscale nodes list -o json` on a timer to dump status information in a machine-readable state.
adam commented 2025-12-29 02:19:59 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 20, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Apr 20, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:59 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 20, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Jul 20, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:59 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 27, 2024):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Jul 27, 2024): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 02:20:00 +01:00
Author
Owner
Copy Link

@npry commented on GitHub (Oct 6, 2025):

Another usecase: I'd love to have a webhook fire when a device or user is added/modified/deleted so I can monitor via gotify

@npry commented on GitHub (Oct 6, 2025): Another usecase: I'd love to have a webhook fire when a device or user is added/modified/deleted so I can monitor via [gotify](https://gotify.net/)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement help wanted needs design doc no-stale-bot
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#553
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?