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

New release? #736

New Issue
Closed
opened 2025-12-29 02:23:04 +01:00 by adam · 6 comments
adam commented 2025-12-29 02:23:04 +01:00
Owner
Copy Link

Originally created by @aaruni96 on GitHub (Jun 23, 2024).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

The last release was in May 2023, which is what apt installs (0.22.3). In particular, this means #1480 is not included in the latest release available on debian.

Are there any plans on making a non-alpha release soon-ish ?

Expected Behavior

n/a

Steps To Reproduce

n/a

Environment

- OS: Debian 12
- Headscale version: 0.22.2
- Tailscale version: N/A

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Anything else?

No response

Originally created by @aaruni96 on GitHub (Jun 23, 2024). ### Is this a support request? - [X] This is not a support request ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior The last release was in May 2023, which is what apt installs (0.22.3). In particular, this means #1480 is not included in the latest release available on debian. Are there any plans on making a non-alpha release soon-ish ? ### Expected Behavior n/a ### Steps To Reproduce n/a ### Environment ```markdown - OS: Debian 12 - Headscale version: 0.22.2 - Tailscale version: N/A ``` ### Runtime environment - [X] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ### Anything else? _No response_
adam added the bug label 2025-12-29 02:23:04 +01:00
adam closed this issue 2025-12-29 02:23:04 +01:00
adam commented 2025-12-29 02:23:05 +01:00
Author
Owner
Copy Link

@markcst commented on GitHub (Jun 30, 2024):

Hope this wonderful project won't be abandoned

@markcst commented on GitHub (Jun 30, 2024): Hope this wonderful project won't be abandoned
adam commented 2025-12-29 02:23:05 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jul 4, 2024):

It's not abandoned, and it's being quite actively developed if you look at the commit history.

The work that was started to make the code more maintainable and easier for us to bring forward unveiled a lot more work than we anticipated which is why the release has taken so much longer than anticipated.

Since the changes are vast, we have opted for releasing it very conservatively with a lot of alphas, and working with people to help us test it in live systems that isn't the same as we run personally.

All this said, the milestone and new bugs from the alphas have almost no issues left, and one big PR to get in and then we should be doing a beta.

I imagine that the beta would reveal some more things here and there as more people might test it, but at large I expect to be able to release not too much later after that.

Thanks for you patience

@kradalby commented on GitHub (Jul 4, 2024): It's not abandoned, and it's being quite actively developed if you look at the commit history. The work that was started to make the code more maintainable and easier for us to bring forward unveiled a lot more work than we anticipated which is why the release has taken so much longer than anticipated. Since the changes are vast, we have opted for releasing it very conservatively with a lot of alphas, and working with people to help us test it in live systems that isn't the same as we run personally. All this said, the milestone and new bugs from the alphas have almost no issues left, and one big PR to get in and then we should be doing a beta. I imagine that the beta would reveal some more things here and there as more people might test it, but at large I expect to be able to release not too much later after that. Thanks for you patience
adam commented 2025-12-29 02:23:05 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jul 13, 2024):

I answered some comments regarding release and performance in Discord and I figured I'll copy them here for people not on discord and so they dont get lost in the history.

r000t: Did anybody else see that Github issue where someone benchmarked sqlite vs postgres?

kradalby: Let me try to address some of these comments:
I think the focus on how the different dbs perform is a bit looking at the wrong thing, SQLite can support this use case by a longshot and its mostly due to Headscale that it doesnt scale. The minor diff between sqlite and psql probably comes down to something with our current code, and the strength of the different db engines.

There has been little focus on speeding up headscale, the reason for this is that before the 0.23 version, we had a lot of technical debt that made changing anything at all hard. 0.23 changes up the architecture a lot, allow us to improve things a bit faster with a bit more confidence.
However, I want to underline that there has been very few effort to make it more performant, as such a large rewrite would cause us to break things that was already working and we lacked tests. This is the reason why we have had so many alphas and over time we have managed to cover the test gap and are more confident that the new code is correct. I think we are getting quite close to at least move it up to a beta, and the biggest help would be for more people to help testing when we get there.

chriswiggins: It’s more to do with the fact that they were all simultaneous. But agree @r000t I think there is some overly eager database joins going on, and perhaps some places where the whole model is loaded from the database, where all that’s required is the nodeId.

kradalby: As per database, originially we made a choice to go with supporting multiple DBs and also using a ORM to do so, one challenge with that is that it makes it harder to optimise any of the databases so you get stuck with the lowest common denominator. The ORM is kind of the same, but for query efficiency, you end up with the thing that works for all.

chriswiggins: I think the next release is nearing, @kradalby is chipping away! We are seriously looking to move to headscale from OpenVPN for our fleet of IoT devices, so I’m putting my hand up to help with finalising it - what are the biggest outstanding tasks?

kradalby: As for this, we are happy to receive help, but we are hesitant to have too many things change at the time, and while we are closing in on getting certain things into shape so this can be improved, we do have other priorities before we can tackle it. For example, I think that the current shape of the OIDC and particularly ACL/Policy is not great, it fails in a bunch of unexpected ways and does not behave in the way Tailscale documents, which is what we strive for. We are likely to focus on improving things like that, essential things to get correct, before we continue on to look at performance/scaling.

kradalby: I realise that we are not that good at publishing what we prioritise/work on, but I'll try to improve that, its just that in between triaging, fixing bugs and trying to improve stuff, it is hard to find time to do that too. We are def not blocking performance improvement, but if we are trying to get things right, it is going to be increasingly hard to make sure things dont break if things are also changing in the other side of the codebase

@kradalby commented on GitHub (Jul 13, 2024): I answered some [comments regarding release and performance in Discord](https://discord.com/channels/896711691637780480/896711692120129540/1261606011882442844) and I figured I'll copy them here for people not on discord and so they dont get lost in the history. > r000t: Did anybody else see that Github issue where someone benchmarked sqlite vs postgres? > kradalby: Let me try to address some of these comments: > I think the focus on how the different dbs perform is a bit looking at the wrong thing, SQLite can support this use case by a longshot and its _mostly_ due to Headscale that it doesnt scale. The minor diff between sqlite and psql probably comes down to something with our current code, and the strength of the different db engines. > > There has been little focus on speeding up headscale, the reason for this is that before the 0.23 version, we had a lot of technical debt that made changing anything at all hard. 0.23 changes up the architecture a lot, allow us to improve things a bit faster with a bit more confidence. However, I want to underline that there has been very few effort to make it more performant, as such a large rewrite would cause us to break things that was already working and we lacked tests. This is the reason why we have had so many alphas and over time we have managed to cover the test gap and are more confident that the new code is correct. I think we are getting quite close to at least move it up to a beta, and the biggest help would be for more people to help testing when we get there. > chriswiggins: It’s more to do with the fact that they were all simultaneous. But agree @r000t I think there is some overly eager database joins going on, and perhaps some places where the whole model is loaded from the database, where all that’s required is the nodeId. > kradalby: As per database, originially we made a choice to go with supporting multiple DBs and also using a ORM to do so, one challenge with that is that it makes it harder to optimise any of the databases so you get stuck with the lowest common denominator. The ORM is kind of the same, but for query efficiency, you end up with the thing that works for all. > chriswiggins: I think the next release is nearing, @kradalby is chipping away! We are seriously looking to move to headscale from OpenVPN for our fleet of IoT devices, so I’m putting my hand up to help with finalising it - what are the biggest outstanding tasks? > kradalby: As for this, we are happy to receive help, but we are hesitant to have too many things change at the time, and while we are closing in on getting certain things into shape so this can be improved, we do have other priorities before we can tackle it. For example, I think that the current shape of the OIDC and particularly ACL/Policy is not great, it fails in a bunch of unexpected ways and does not behave in the way Tailscale documents, which is what we strive for. We are likely to focus on improving things like that, essential things to get correct, before we continue on to look at performance/scaling. > kradalby: I realise that we are not that good at publishing what we prioritise/work on, but I'll try to improve that, its just that in between triaging, fixing bugs and trying to improve stuff, it is hard to find time to do that too. We are def not blocking performance improvement, but if we are trying to get things right, it is going to be increasingly hard to make sure things dont break if things are also changing in the other side of the codebase
adam commented 2025-12-29 02:23:06 +01:00
Author
Owner
Copy Link

@aaruni96 commented on GitHub (Jul 14, 2024):

Thanks for the update for the rest of the class (people like me, not on discord).

Really appreciate the work you guys are putting in. Working on some other projects, I know its not easy to work, and talk about the work at the same time.

Couple questions:

  • Is it "safe" to use the alpha builds. I was under the impression that there's a headscale apt repo, and updates would appear there, but I went back and checked, and its a local install. So, I could just install the latest alpha over the current install, and it should mostly work ?
    By "safe", I just mean it won't fall over and take my whole server down with it, or accidentally issue an rm -rvf / on the clients or something.
  • Are there any plans on having an apt repo? Is that too much to ask for at this time ?
@aaruni96 commented on GitHub (Jul 14, 2024): Thanks for the update for the rest of the class (people like me, not on discord). Really appreciate the work you guys are putting in. Working on some other projects, I know its not easy to work, and talk about the work at the same time. Couple questions: - Is it "safe" to use the alpha builds. I was under the impression that there's a headscale apt repo, and updates would appear there, but I went back and checked, and its a local install. So, I could just install the latest alpha over the current install, and it should mostly work ? By "safe", I just mean it won't fall over and take my whole server down with it, or accidentally issue an `rm -rvf /` on the clients or something. - Are there any plans on having an apt repo? Is that too much to ask for at this time ?
adam commented 2025-12-29 02:23:06 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jul 17, 2024):

Is it "safe" to use the alpha builds. By "safe", I just mean it won't fall over and take my whole server down with it, or accidentally issue an rm -rvf / on the clients or something.

It is a hard question to answer, but I would say that I dont think the alpha is any more likely to take down or rm -rf your server any more than any previous release of Headscale.

I use it in my installations, and I know other people with relatively sophisticated setups also do.
The new release is mostly wins, I would say that the "major risk" is that there might be regressions from 0.22.3, but I'm fairly confident most of them are now fixed.

Are there any plans on having an apt repo? Is that too much to ask for at this time ?

Tracked here https://github.com/juanfont/headscale/issues/1526

@kradalby commented on GitHub (Jul 17, 2024): > Is it "safe" to use the alpha builds. By "safe", I just mean it won't fall over and take my whole server down with it, or accidentally issue an rm -rvf / on the clients or something. It is a hard question to answer, but I would say that I dont think the alpha is any more likely to take down or `rm -rf` your server any more than any previous release of Headscale. I use it in my installations, and I know other people with relatively sophisticated setups also do. The new release is mostly wins, I would say that the "major risk" is that there might be regressions from 0.22.3, but I'm fairly confident most of them are now fixed. > Are there any plans on having an apt repo? Is that too much to ask for at this time ? Tracked here https://github.com/juanfont/headscale/issues/1526
adam commented 2025-12-29 02:23:06 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 18, 2024):

Done :)

@kradalby commented on GitHub (Sep 18, 2024): Done :)
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 bug
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#736
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?