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

v0.23.0 image tag available on Docker but not on project #638

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

Originally created by @guyguy333 on GitHub (Feb 15, 2024).

Bug description

I'm not sure it's a bug but I've been notified that a new image tag has been released on Docker Hub : 0.23.0
However, latest version is always an alpha on GitHub project. Is it expected to have this image published as a stable tag ?

https://hub.docker.com/layers/headscale/headscale/0.23.0/images/sha256-9e95e62d1c59a51bb5688737dd38b5d149cea44502a7c76ff668c07d9e8ff4c9?context=explore

Originally created by @guyguy333 on GitHub (Feb 15, 2024). <!-- Before posting a bug report, discuss the behaviour you are expecting with the Discord community to make sure that it is truly a bug. The issue tracker is not the place to ask for support or how to set up Headscale. Bug reports without the sufficient information will be closed. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Bug description <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> I'm not sure it's a bug but I've been notified that a new image tag has been released on Docker Hub : 0.23.0 However, latest version is always an alpha on GitHub project. Is it expected to have this image published as a stable tag ? https://hub.docker.com/layers/headscale/headscale/0.23.0/images/sha256-9e95e62d1c59a51bb5688737dd38b5d149cea44502a7c76ff668c07d9e8ff4c9?context=explore
adam added the bug label 2025-12-29 02:21:28 +01:00
adam closed this issue 2025-12-29 02:21:28 +01:00
adam commented 2025-12-29 02:21:29 +01:00
Author
Owner
Copy Link

@CoolnsX commented on GitHub (Feb 15, 2024):

The problem is it's not working, my watchtower updated my headscale, and it started going in restart loop, so I read logs and log says

  • "headscale serve" not found try headscale --help

so I figured that they set the entrypoint directly to headscale so I removed "headscale" from "headscale serve" in "command"
So now it's giving error -- 2024-02-15T20:52:14Z FTL invalid database type "", must be sqlite, sqlite3 or postgres

I have stopped the headscale container for now, I will do it later some time

@CoolnsX commented on GitHub (Feb 15, 2024): The problem is it's not working, my watchtower updated my headscale, and it started going in restart loop, so I read logs and log says - "headscale serve" not found try headscale --help so I figured that they set the entrypoint directly to headscale so I removed "headscale" from "headscale serve" in "command" So now it's giving error -- 2024-02-15T20:52:14Z FTL invalid database type "", must be sqlite, sqlite3 or postgres I have stopped the headscale container for now, I will do it later some time
adam commented 2025-12-29 02:21:29 +01:00
Author
Owner
Copy Link

@epichub commented on GitHub (Feb 15, 2024):

struggled with the same sudden change in entrypoint, this post helped, found out the db config part had changed for the next problem:

database:
  type: sqlite

  # SQLite config
  sqlite:
    path: /var/lib/headscale/db.sqlite

vs the old

db_type: sqlite3
db_path: /etc/headscale/db.sqlite

(from https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml)

@epichub commented on GitHub (Feb 15, 2024): struggled with the same sudden change in entrypoint, this post helped, found out the db config part had changed for the next problem: ``` database: type: sqlite # SQLite config sqlite: path: /var/lib/headscale/db.sqlite ``` vs the old ``` db_type: sqlite3 db_path: /etc/headscale/db.sqlite ``` (from https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml)
adam commented 2025-12-29 02:21:29 +01:00
Author
Owner
Copy Link

@muchachagrande commented on GitHub (Feb 16, 2024):

The "latest" tag is now pointing to 0.23 alpha 4

@muchachagrande commented on GitHub (Feb 16, 2024): The "latest" tag is now pointing to 0.23 alpha 4
adam commented 2025-12-29 02:21:30 +01:00
Author
Owner
Copy Link

@nikolas-digitalBabylon commented on GitHub (Feb 16, 2024):

The "latest" tag is now pointing to 0.23 alpha 4

Is this really how it should be? According to docker hub the tags 0.23, 0.23-alpha4, and unstable all have the same digest. Is that what is expected, or is it some issue with a ci/cd pipeline?

@nikolas-digitalBabylon commented on GitHub (Feb 16, 2024): > The "latest" tag is now pointing to 0.23 alpha 4 Is this really how it should be? According to docker hub the tags 0.23, 0.23-alpha4, and unstable all have the same digest. Is that what is expected, or is it some issue with a ci/cd pipeline?
adam commented 2025-12-29 02:21:30 +01:00
Author
Owner
Copy Link

@CoolnsX commented on GitHub (Feb 16, 2024):

I think CI/CD pipeline issue here

@CoolnsX commented on GitHub (Feb 16, 2024): I think CI/CD pipeline issue here
adam commented 2025-12-29 02:21:30 +01:00
Author
Owner
Copy Link

@TehNomad commented on GitHub (Feb 16, 2024):

The problem is it's not working, my watchtower updated my headscale, and it started going in restart loop, so I read logs and log says

* "headscale serve" not found try headscale --help

so I figured that they set the entrypoint directly to headscale so I removed "headscale" from "headscale serve" in "command" So now it's giving error -- 2024-02-15T20:52:14Z FTL invalid database type "", must be sqlite, sqlite3 or postgres

I have stopped the headscale container for now, I will do it later some time

struggled with the same sudden change in entrypoint, this post helped, found out the db config part had changed for the next problem:

database:
  type: sqlite

  # SQLite config
  sqlite:
    path: /var/lib/headscale/db.sqlite

vs the old

db_type: sqlite3
db_path: /etc/headscale/db.sqlite

(from https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml)

These two changes solved almost all the issues, but I also had the following error:

headscale | 2024-02-16T08:11:05Z FTL home/runner/work/headscale/headscale/cmd/headscale/cli/server.go:26 > Error starting server error="failed to set up gRPC socket: listen unix /var/run/headscale/headscale.sock: bind: no such file or directory"

Which I solved by adding a new volume to my docker-compose.yml file:

volumes:
  - ...
  - /var/run/headscale

Now, headscale is running fine in a docker container.

@TehNomad commented on GitHub (Feb 16, 2024): > The problem is it's not working, my watchtower updated my headscale, and it started going in restart loop, so I read logs and log says > > * "headscale serve" not found try headscale --help > > > so I figured that they set the entrypoint directly to headscale so I removed "headscale" from "headscale serve" in "command" So now it's giving error -- 2024-02-15T20:52:14Z FTL invalid database type "", must be sqlite, sqlite3 or postgres > > I have stopped the headscale container for now, I will do it later some time > struggled with the same sudden change in entrypoint, this post helped, found out the db config part had changed for the next problem: > > ``` > database: > type: sqlite > > # SQLite config > sqlite: > path: /var/lib/headscale/db.sqlite > ``` > > vs the old > > ``` > db_type: sqlite3 > db_path: /etc/headscale/db.sqlite > ``` > > (from https://raw.githubusercontent.com/juanfont/headscale/main/config-example.yaml) These two changes solved almost all the issues, but I also had the following error: `headscale | 2024-02-16T08:11:05Z FTL home/runner/work/headscale/headscale/cmd/headscale/cli/server.go:26 > Error starting server error="failed to set up gRPC socket: listen unix /var/run/headscale/headscale.sock: bind: no such file or directory"` Which I solved by adding a new volume to my docker-compose.yml file: ``` volumes: - ... - /var/run/headscale ``` Now, headscale is running fine in a docker container.
adam commented 2025-12-29 02:21:31 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 16, 2024):

Sorry about this, the tags was an issue and #1763 should address it for the future.

Will make amendments to the Changelog for other things.

@kradalby commented on GitHub (Feb 16, 2024): Sorry about this, the tags was an issue and #1763 should address it for the future. Will make amendments to the Changelog for other things.
adam commented 2025-12-29 02:21:31 +01:00
Author
Owner
Copy Link

@troycarpenter commented on GitHub (Feb 16, 2024):

This bit me yesterday as well. Docker compose pulled the alpha release and nothing worked after that. I did try by making the config.yaml changes, but the database changes were enough to have all my machines nodes disappear and request re-registration.

I changed the image tag to 0.22.3, reverted my config changes and everything is back again.

A little more warning next time, please.

@troycarpenter commented on GitHub (Feb 16, 2024): This bit me yesterday as well. Docker compose pulled the alpha release and nothing worked after that. I did try by making the config.yaml changes, but the database changes were enough to have all my ~~machines~~ nodes disappear and request re-registration. I changed the image tag to 0.22.3, reverted my config changes and everything is back again. A little more warning next time, please.
adam commented 2025-12-29 02:21:31 +01:00
Author
Owner
Copy Link

@epichub commented on GitHub (Feb 17, 2024):

I would like to add that i love headscale - and tailscale.
I think its a great, and more importantly very useful, piece of software.

And I am absolutely sure that this was a good old mistake.

And as a result, that if the developers knew it was going to happen - they would have given us that heads up :)

@epichub commented on GitHub (Feb 17, 2024): I would like to add that i love headscale - and tailscale. I think its a great, and more importantly very useful, piece of software. And I am absolutely sure that this was a good old mistake. And as a result, that if the developers knew it was going to happen - they would have given us that heads up :)
adam commented 2025-12-29 02:21:31 +01:00
Author
Owner
Copy Link

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

Thanks.

This was an accident, we did review the new tags as part of the pipeline, but not all the impact occured to us. As we often state, we do not use docker ourselves so we dont grasp all the ways people use it.

In this case there were several problems:

The last one is very unfortunate as it looks safe to upgrade, and I am extra sorry for that.

When it comes to latest, I would personally recommend everyone to avoid that for all their containers as you loose a lot of control of your own infrastructure and are very vulnerable to both mistakes like this, but also supply chain attacks.

@kradalby commented on GitHub (Feb 17, 2024): Thanks. This was an accident, we did review the new tags as part of the pipeline, but not all the impact occured to us. As we often state, we do not use docker ourselves so we dont grasp all the ways people use it. In this case there were several problems: - Database changes that was suppose to be aliased did not work (fixed in https://github.com/juanfont/headscale/pull/1766) - The entrypoint change of the docker container was not understood and documented (fixed in https://github.com/juanfont/headscale/pull/1763) - latest was replaced by alpha (fixed in https://github.com/juanfont/headscale/pull/1763) - major, minor and patch was pushed as part of prerelease (fixed in https://github.com/juanfont/headscale/pull/1763) The last one is very unfortunate as it looks safe to upgrade, and I am extra sorry for that. When it comes to latest, I would personally recommend everyone to avoid that for all their containers as you loose a lot of control of your own infrastructure and are very vulnerable to both mistakes like this, but also supply chain attacks.
adam commented 2025-12-29 02:21:31 +01:00
Author
Owner
Copy Link

@artis3n commented on GitHub (Feb 17, 2024):

Thanks for this update and quick resolution! I wanted to confirm - have the docker hub tags been fixed? https://github.com/juanfont/headscale/pull/1763#issuecomment-1948431759

https://hub.docker.com/r/headscale/headscale/tags still seems to show the 0.23 and latest tags pointing to the bad SHAs

@artis3n commented on GitHub (Feb 17, 2024): Thanks for this update and quick resolution! I wanted to confirm - have the docker hub tags been fixed? https://github.com/juanfont/headscale/pull/1763#issuecomment-1948431759 https://hub.docker.com/r/headscale/headscale/tags still seems to show the 0.23 and latest tags pointing to the bad SHAs
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 19, 2024):

We have released alpha5 now, the tags are no longer written incorrectly, we have also done the following:

Deleted 0, 0.23, 0.23.0.
Untagged latest, we will not replace this until we do another stable to avoid accidents.

@kradalby commented on GitHub (Feb 19, 2024): We have released alpha5 now, the tags are no longer written incorrectly, we have also done the following: Deleted 0, 0.23, 0.23.0. Untagged latest, we will not replace this until we do another stable to avoid accidents.
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@CoolnsX commented on GitHub (Feb 19, 2024):

so, I think I am going to stick with alpha5 since I have updated my config.yml file and made changes in my docker-compose too, and I will wait until 0.23 is released.

@CoolnsX commented on GitHub (Feb 19, 2024): so, I think I am going to stick with alpha5 since I have updated my config.yml file and made changes in my docker-compose too, and I will wait until 0.23 is released.
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@nikolas-digitalBabylon commented on GitHub (Feb 19, 2024):

We have released alpha5 now, the tags are no longer written incorrectly, we have also done the following:

Deleted 0, 0.23, 0.23.0. Untagged latest, we will not replace this until we do another stable to avoid accidents.

Thanks for all this. If I get it right, previously deployed containers will still be deployed on an "alpha" version.
Is a downgrade possible to the last stable release? I assume the alpha5 still might have bugs / security issues and a downgrade makes sense.

@nikolas-digitalBabylon commented on GitHub (Feb 19, 2024): > We have released alpha5 now, the tags are no longer written incorrectly, we have also done the following: > > Deleted 0, 0.23, 0.23.0. Untagged latest, we will not replace this until we do another stable to avoid accidents. Thanks for all this. If I get it right, previously deployed containers will still be deployed on an "alpha" version. Is a downgrade possible to the last stable release? I assume the alpha5 still might have bugs / security issues and a downgrade makes sense.
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 19, 2024):

Downgrade would require rolling back to a database backup, and changing back your config. If you have a recent database then yes.

@kradalby commented on GitHub (Feb 19, 2024): Downgrade would require rolling back to a database backup, and changing back your config. If you have a recent database then yes.
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@nikolas-digitalBabylon commented on GitHub (Feb 19, 2024):

I cannot tell what kind of issues the alpha5 might present to those running it, but I would suggest that a downgrade path to the actual stable release is communicated.

Thanks again!

@nikolas-digitalBabylon commented on GitHub (Feb 19, 2024): I cannot tell what kind of issues the alpha5 might present to those running it, but I would suggest that a downgrade path to the actual stable release is communicated. Thanks again!
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@guyguy333 commented on GitHub (Feb 21, 2024):

We have released alpha5 now, the tags are no longer written incorrectly, we have also done the following:

Deleted 0, 0.23, 0.23.0. Untagged latest, we will not replace this until we do another stable to avoid accidents.

Thanks @kradalby

On my side, I can still see 0.23.0 tag on Docker Hub https://hub.docker.com/layers/headscale/headscale/0.23.0/images/sha256-9e95e62d1c59a51bb5688737dd38b5d149cea44502a7c76ff668c07d9e8ff4c9?context=explore

Also https://hub.docker.com/layers/headscale/headscale/0.23.0-debug/images/sha256-9084af941716122990f3c43ad944b6d0cac95d1e7ae48f5b7e425ff92f2a6fbf?context=explore

@guyguy333 commented on GitHub (Feb 21, 2024): > We have released alpha5 now, the tags are no longer written incorrectly, we have also done the following: > > Deleted 0, 0.23, 0.23.0. Untagged latest, we will not replace this until we do another stable to avoid accidents. Thanks @kradalby On my side, I can still see 0.23.0 tag on Docker Hub https://hub.docker.com/layers/headscale/headscale/0.23.0/images/sha256-9e95e62d1c59a51bb5688737dd38b5d149cea44502a7c76ff668c07d9e8ff4c9?context=explore Also https://hub.docker.com/layers/headscale/headscale/0.23.0-debug/images/sha256-9084af941716122990f3c43ad944b6d0cac95d1e7ae48f5b7e425ff92f2a6fbf?context=explore
adam commented 2025-12-29 02:21:32 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Feb 21, 2024):

@guyguy333 should be now fixed :)

@juanfont commented on GitHub (Feb 21, 2024): @guyguy333 should be now fixed :)
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#638
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?