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] Helm Chart #1075

New Issue
Closed
opened 2025-12-29 02:28:08 +01:00 by adam · 4 comments
adam commented 2025-12-29 02:28:08 +01:00
Owner
Copy Link

Originally created by @acullenn on GitHub (Aug 4, 2025).

Use case

For simplifying deployment of Headscale to Kubernetes clusters

Description

I'm planning on writing a Helm Chart for headscale for personal usage, and was wondering if the maintainers felt there would be value to having it in the main project repo. I'm happy to stage a PR with my fork, if so.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

Since Headscale has a public Docker image + release process already:

I think all we need to implement this is to:

  • Create a Helm Chart
  • Modify the Release process to add a step to increment the Helm Chart appVersion in step with the container version
    • Some combination of goReleaser configuration and maybe https://github.com/helm/chart-releaser? I'm not super familiar with goreleaser, so I'm unsure if this is the right approach.
      • Seems like we could add a sed -i -E "s/(appVersion:).*/\1 {{ .Version }}/" charts/headscale/Chart.yaml in the hooks?
    • Since this project is already using ghcr as a container registry, I figure we can pigyback on that and have it double as a helm chart registry.
Originally created by @acullenn on GitHub (Aug 4, 2025). ### Use case For simplifying deployment of Headscale to Kubernetes clusters ### Description I'm planning on writing a Helm Chart for headscale for personal usage, and was wondering if the maintainers felt there would be value to having it in the main project repo. I'm happy to stage a PR with my fork, if so. ### Contribution - [x] I can write the design doc for this feature - [x] I can contribute this feature ### How can it be implemented? Since Headscale has a public Docker image + release process already: - https://ghcr.io/juanfont/headscale I think all we need to implement this is to: - Create a Helm Chart - Modify the Release process to add a step to increment the Helm Chart appVersion in step with the container version - Some combination of `goReleaser` configuration and maybe https://github.com/helm/chart-releaser? I'm not super familiar with goreleaser, so I'm unsure if this is the right approach. - Seems like we could add a `sed -i -E "s/(appVersion:).*/\1 {{ .Version }}/" charts/headscale/Chart.yaml` in the hooks? - Since this project is already using `ghcr` as a container registry, I figure we can pigyback on that and have it double as a helm chart registry.
adam added the enhancement label 2025-12-29 02:28:08 +01:00
adam closed this issue 2025-12-29 02:28:08 +01:00
adam commented 2025-12-29 02:28:08 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Aug 5, 2025):

Hi, I think the challenge would be to keep it maintained over time. I dont really have the knowledge to review Helm charts, and since they are particularly hard to validate and test, I would not know how to make sure we do not break it over time. So having it as part of the main repo is problematic as it would likely bit rot and people will, no matter how much we write that it isnt officially supported, expect it to be. And then we will get the support load.

I do appreciate that this comes from wanting to contribute and we do really appreciate it, but in this modern day of N ways to deploy and run things time X (opinions) and Z (versions). It becomes difficult for us to support more than a few "old school ways".

@kradalby commented on GitHub (Aug 5, 2025): Hi, I think the challenge would be to keep it maintained over time. I dont really have the knowledge to review Helm charts, and since they are particularly hard to validate and test, I would not know how to make sure we do not break it over time. So having it as part of the main repo is problematic as it would likely bit rot and people will, no matter how much we write that it isnt officially supported, expect it to be. And then we will get the support load. I do appreciate that this comes from wanting to contribute and we do really appreciate it, but in this modern day of N ways to deploy and run things time X (opinions) and Z (versions). It becomes difficult for us to support more than a few "old school ways".
adam commented 2025-12-29 02:28:09 +01:00
Author
Owner
Copy Link

@acullenn commented on GitHub (Aug 6, 2025):

Hi @kradalby, thanks for the reply. No problem at all, I totally understand the need to control the scope of maintenance burden.

If anything changes in the future, and you'd like some assistance implementing it, feel free to reach out and I'd be happy to contribute!

Closing this Issue out ~

@acullenn commented on GitHub (Aug 6, 2025): Hi @kradalby, thanks for the reply. No problem at all, I totally understand the need to control the scope of maintenance burden. If anything changes in the future, and you'd like some assistance implementing it, feel free to reach out and I'd be happy to contribute! Closing this Issue out ~
adam commented 2025-12-29 02:28:09 +01:00
Author
Owner
Copy Link

@joshuacox commented on GitHub (Oct 28, 2025):

@acullenn would you link to your helm chart though? I'd like to contribute to it as well.

@joshuacox commented on GitHub (Oct 28, 2025): @acullenn would you link to your helm chart though? I'd like to contribute to it as well.
adam commented 2025-12-29 02:28:09 +01:00
Author
Owner
Copy Link

@kervel commented on GitHub (Nov 4, 2025):

i have been working on one too for internal use: https://github.com/Kapernikov/headscale-helm

it runs heascale and optionally a tailscale client in-cluster (the idea is to later make select kubernetes services available to headscale clients, or maybe serve as a peer relay when that's working)

@kervel commented on GitHub (Nov 4, 2025): i have been working on one too for internal use: https://github.com/Kapernikov/headscale-helm it runs heascale and optionally a tailscale client in-cluster (the idea is to later make select kubernetes services available to headscale clients, or maybe serve as a peer relay when that's working)
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
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#1075
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?