diff --git a/development/404.html b/development/404.html index da422361..6d43edec 100644 --- a/development/404.html +++ b/development/404.html @@ -1 +1 @@ - Headscale

404 - Not found

\ No newline at end of file + Headscale

404 - Not found

\ No newline at end of file diff --git a/development/about/clients/index.html b/development/about/clients/index.html index c0c83585..3279a1b9 100644 --- a/development/about/clients/index.html +++ b/development/about/clients/index.html @@ -1 +1 @@ - Clients - Headscale
Skip to content

Client and operating system support

We aim to support the last 10 releases of the Tailscale client on all provided operating systems and platforms. Some platforms might require additional configuration to connect with headscale.

OS Supports headscale
Linux Yes
OpenBSD Yes
FreeBSD Yes
Windows Yes (see docs and /windows on your headscale for more information)
Android Yes (see docs for more information)
macOS Yes (see docs and /apple on your headscale for more information)
iOS Yes (see docs and /apple on your headscale for more information)
tvOS Yes (see docs and /apple on your headscale for more information)
\ No newline at end of file + Clients - Headscale
Skip to content

Client and operating system support

We aim to support the last 10 releases of the Tailscale client on all provided operating systems and platforms. Some platforms might require additional configuration to connect with headscale.

OS Supports headscale
Linux Yes
OpenBSD Yes
FreeBSD Yes
Windows Yes (see docs and /windows on your headscale for more information)
Android Yes (see docs for more information)
macOS Yes (see docs and /apple on your headscale for more information)
iOS Yes (see docs and /apple on your headscale for more information)
tvOS Yes (see docs and /apple on your headscale for more information)
\ No newline at end of file diff --git a/development/about/contributing/index.html b/development/about/contributing/index.html index 15b54664..097496f2 100644 --- a/development/about/contributing/index.html +++ b/development/about/contributing/index.html @@ -1 +1 @@ - Contributing - Headscale
Skip to content

Contributing

Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the maintainers before being added to the project. This model has been chosen to reduce the risk of burnout by limiting the maintenance overhead of reviewing and validating third-party code.

Why do we have this model?

Headscale has a small maintainer team that tries to balance working on the project, fixing bugs and reviewing contributions.

When we work on issues ourselves, we develop first hand knowledge of the code and it makes it possible for us to maintain and own the code as the project develops.

Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during the reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly.

The review and day-1 maintenance adds a significant burden on the maintainers. Often we hope that the contributor will help out, but we found that most of the time, they disappear after their new feature was added.

This means that when someone contributes, we are mostly happy about it, but we do have to run it through a series of checks to establish if we actually can maintain this feature.

What do we require?

A general description is provided here and an explicit list is provided in our pull request template.

All new features have to start out with a design document, which should be discussed on the issue tracker (not discord). It should include a use case for the feature, how it can be implemented, who will implement it and a plan for maintaining it.

All features have to be end-to-end tested (integration tests) and have good unit test coverage to ensure that they work as expected. This will also ensure that the feature continues to work as expected over time. If a change cannot be tested, a strong case for why this is not possible needs to be presented.

The contributor should help to maintain the feature over time. In case the feature is not maintained probably, the maintainers reserve themselves the right to remove features they redeem as unmaintainable. This should help to improve the quality of the software and keep it in a maintainable state.

Bug fixes

Headscale is open to code contributions for bug fixes without discussion.

Documentation

If you find mistakes in the documentation, please submit a fix to the documentation.

\ No newline at end of file + Contributing - Headscale
Skip to content

Contributing

Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the maintainers before being added to the project. This model has been chosen to reduce the risk of burnout by limiting the maintenance overhead of reviewing and validating third-party code.

Why do we have this model?

Headscale has a small maintainer team that tries to balance working on the project, fixing bugs and reviewing contributions.

When we work on issues ourselves, we develop first hand knowledge of the code and it makes it possible for us to maintain and own the code as the project develops.

Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during the reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly.

The review and day-1 maintenance adds a significant burden on the maintainers. Often we hope that the contributor will help out, but we found that most of the time, they disappear after their new feature was added.

This means that when someone contributes, we are mostly happy about it, but we do have to run it through a series of checks to establish if we actually can maintain this feature.

What do we require?

A general description is provided here and an explicit list is provided in our pull request template.

All new features have to start out with a design document, which should be discussed on the issue tracker (not discord). It should include a use case for the feature, how it can be implemented, who will implement it and a plan for maintaining it.

All features have to be end-to-end tested (integration tests) and have good unit test coverage to ensure that they work as expected. This will also ensure that the feature continues to work as expected over time. If a change cannot be tested, a strong case for why this is not possible needs to be presented.

The contributor should help to maintain the feature over time. In case the feature is not maintained probably, the maintainers reserve themselves the right to remove features they redeem as unmaintainable. This should help to improve the quality of the software and keep it in a maintainable state.

Bug fixes

Headscale is open to code contributions for bug fixes without discussion.

Documentation

If you find mistakes in the documentation, please submit a fix to the documentation.

\ No newline at end of file diff --git a/development/about/faq/index.html b/development/about/faq/index.html index 9e94522d..15c9d89b 100644 --- a/development/about/faq/index.html +++ b/development/about/faq/index.html @@ -1 +1 @@ - FAQ - Headscale
Skip to content

Frequently Asked Questions

What is the design goal of headscale?

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.

How can I contribute?

Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the Maintainers before being submitted.

Please see Contributing for more information.

Why is 'acknowledged contribution' the chosen model?

Both maintainers have full-time jobs and families, and we want to avoid burnout. We also want to avoid frustration from contributors when their PRs are not accepted.

We are more than happy to exchange emails, or to have dedicated calls before a PR is submitted.

When/Why is Feature X going to be implemented?

We don't know. We might be working on it. If you're interested in contributing, please post a feature request about it.

Please be aware that there are a number of reasons why we might not accept specific contributions:

  • It is not possible to implement the feature in a way that makes sense in a self-hosted environment.
  • Given that we are reverse-engineering Tailscale to satisfy our own curiosity, we might be interested in implementing the feature ourselves.
  • You are not sending unit and integration tests with it.

Do you support Y method of deploying headscale?

We currently support deploying headscale using our binaries and the DEB packages. Visit our installation guide using official releases for more information.

In addition to that, you may use packages provided by the community or from distributions. Learn more in the installation guide using community packages.

For convenience, we also build container images with headscale. But please be aware that we don't officially support deploying headscale using Docker. On our Discord server we have a "docker-issues" channel where you can ask for Docker-specific help to the community.

Please follow the steps outlined in the upgrade guide to update your existing Headscale installation. Its best to update from one stable version to the next (e.g. 0.24.0 → 0.25.1 → 0.26.1) in case you are multiple releases behind. You should always pick the latest available patch release.

Be sure to check the changelog for version specific upgrade instructions and breaking changes.

Scaling / How many clients does Headscale support?

It depends. As often stated, Headscale is not enterprise software and our focus is homelabbers and self-hosters. Of course, we do not prevent people from using it in a commercial/professional setting and often get questions about scaling.

Please note that when Headscale is developed, performance is not part of the consideration as the main audience is considered to be users with a modest amount of devices. We focus on correctness and feature parity with Tailscale SaaS over time.

To understand if you might be able to use Headscale for your use case, I will describe two scenarios in an effort to explain what is the central bottleneck of Headscale:

  1. An environment with 1000 servers

  2. they rarely "move" (change their endpoints)

  3. new nodes are added rarely

  4. An environment with 80 laptops/phones (end user devices)

  5. nodes move often, e.g. switching from home to office

Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that requires changes to this map happens, the whole "world" is recalculated, and a new "world map" is created for every node in the network.

This means that under certain conditions, Headscale can likely handle 100s of devices (maybe more), if there is little to no change happening in the network. For example, in Scenario 1, the process of computing the world map is extremely demanding due to the size of the network, but when the map has been created and the nodes are not changing, the Headscale instance will likely return to a very low resource usage until the next time there is an event requiring the new map.

In the case of Scenario 2, the process of computing the world map is less demanding due to the smaller size of the network, however, the type of nodes will likely change frequently, which would lead to a constant resource usage.

Headscale will start to struggle when the two scenarios overlap, e.g. many nodes with frequent changes will cause the resource usage to remain constantly high. In the worst case scenario, the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up, and nodes will never learn about the current state of the world.

We expect that the performance will improve over time as we improve the code base, but it is not a focus. In general, we will never make the tradeoff to make things faster on the cost of less maintainable or readable code. We are a small team and have to optimise for maintainability.

Which database should I use?

We recommend the use of SQLite as database for headscale:

  • SQLite is simple to setup and easy to use
  • It scales well for all of headscale's use cases
  • Development and testing happens primarily on SQLite
  • PostgreSQL is still supported, but is considered to be in "maintenance mode"

The headscale project itself does not provide a tool to migrate from PostgreSQL to SQLite. Please have a look at the related tools documentation for migration tooling provided by the community.

The choice of database has little to no impact on the performance of the server, see Scaling / How many clients does Headscale support? for understanding how Headscale spends its resources.

Why is my reverse proxy not working with headscale?

We don't know. We don't use reverse proxies with headscale ourselves, so we don't have any experience with them. We have community documentation on how to configure various reverse proxies, and a dedicated "reverse-proxy-issues" channel on our Discord server where you can ask for help to the community.

Can I use headscale and tailscale on the same machine?

Running headscale on a machine that is also in the tailnet can cause problems with subnet routers, traffic relay nodes, and MagicDNS. It might work, but it is not supported.

Why do two nodes see each other in their status, even if an ACL allows traffic only in one direction?

A frequent use case is to allow traffic only from one node to another, but not the other way around. For example, the workstation of an administrator should be able to connect to all nodes but the nodes themselves shouldn't be able to connect back to the administrator's node. Why do all nodes see the administrator's workstation in the output of tailscale status?

This is essentially how Tailscale works. If traffic is allowed to flow in one direction, then both nodes see each other in their output of tailscale status. Traffic is still filtered according to the ACL, with the exception of tailscale ping which is always allowed in either direction.

See also https://tailscale.com/kb/1087/device-visibility.

My policy is stored in the database and Headscale refuses to start due to an invalid policy. How can I recover?

Headscale checks if the policy is valid during startup and refuses to start if it detects an error. The error message indicates which part of the policy is invalid. Follow these steps to fix your policy:

  • Dump the policy to a file: headscale policy get --bypass-grpc-and-access-database-directly > policy.json
  • Edit and fixup policy.json. Use the command headscale policy check --file policy.json to validate the policy.
  • Load the modified policy: headscale policy set --bypass-grpc-and-access-database-directly --file policy.json
  • Start Headscale as usual.

Full server configuration required

The above commands to get/set the policy require a complete server configuration file including database settings. A minimal config to control Headscale via remote CLI is not sufficient. You may use headscale -c /path/to/config.yaml to specify the path to an alternative configuration file.

How can I avoid to send logs to Tailscale Inc?

A Tailscale client collects logs about its operation and connection attempts with other clients and sends them to a central log service operated by Tailscale Inc.

Headscale, by default, instructs clients to disable log submission to the central log service. This configuration is applied by a client once it successfully connected with Headscale. See the configuration option logtail.enabled in the configuration file for details.

Alternatively, logging can also be disabled on the client side. This is independent of Headscale and opting out of client logging disables log submission early during client startup. The configuration is operating system specific and is usually achieved by setting the environment variable TS_NO_LOGS_NO_SUPPORT=true or by passing the flag --no-logs-no-support to tailscaled. See https://tailscale.com/kb/1011/log-mesh-traffic#opting-out-of-client-logging for details.

\ No newline at end of file + FAQ - Headscale
Skip to content

Frequently Asked Questions

What is the design goal of headscale?

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.

How can I contribute?

Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the Maintainers before being submitted.

Please see Contributing for more information.

Why is 'acknowledged contribution' the chosen model?

Both maintainers have full-time jobs and families, and we want to avoid burnout. We also want to avoid frustration from contributors when their PRs are not accepted.

We are more than happy to exchange emails, or to have dedicated calls before a PR is submitted.

When/Why is Feature X going to be implemented?

We don't know. We might be working on it. If you're interested in contributing, please post a feature request about it.

Please be aware that there are a number of reasons why we might not accept specific contributions:

  • It is not possible to implement the feature in a way that makes sense in a self-hosted environment.
  • Given that we are reverse-engineering Tailscale to satisfy our own curiosity, we might be interested in implementing the feature ourselves.
  • You are not sending unit and integration tests with it.

Do you support Y method of deploying headscale?

We currently support deploying headscale using our binaries and the DEB packages. Visit our installation guide using official releases for more information.

In addition to that, you may use packages provided by the community or from distributions. Learn more in the installation guide using community packages.

For convenience, we also build container images with headscale. But please be aware that we don't officially support deploying headscale using Docker. On our Discord server we have a "docker-issues" channel where you can ask for Docker-specific help to the community.

Please follow the steps outlined in the upgrade guide to update your existing Headscale installation. Its best to update from one stable version to the next (e.g. 0.24.0 → 0.25.1 → 0.26.1) in case you are multiple releases behind. You should always pick the latest available patch release.

Be sure to check the changelog for version specific upgrade instructions and breaking changes.

Scaling / How many clients does Headscale support?

It depends. As often stated, Headscale is not enterprise software and our focus is homelabbers and self-hosters. Of course, we do not prevent people from using it in a commercial/professional setting and often get questions about scaling.

Please note that when Headscale is developed, performance is not part of the consideration as the main audience is considered to be users with a modest amount of devices. We focus on correctness and feature parity with Tailscale SaaS over time.

To understand if you might be able to use Headscale for your use case, I will describe two scenarios in an effort to explain what is the central bottleneck of Headscale:

  1. An environment with 1000 servers

  2. they rarely "move" (change their endpoints)

  3. new nodes are added rarely

  4. An environment with 80 laptops/phones (end user devices)

  5. nodes move often, e.g. switching from home to office

Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that requires changes to this map happens, the whole "world" is recalculated, and a new "world map" is created for every node in the network.

This means that under certain conditions, Headscale can likely handle 100s of devices (maybe more), if there is little to no change happening in the network. For example, in Scenario 1, the process of computing the world map is extremely demanding due to the size of the network, but when the map has been created and the nodes are not changing, the Headscale instance will likely return to a very low resource usage until the next time there is an event requiring the new map.

In the case of Scenario 2, the process of computing the world map is less demanding due to the smaller size of the network, however, the type of nodes will likely change frequently, which would lead to a constant resource usage.

Headscale will start to struggle when the two scenarios overlap, e.g. many nodes with frequent changes will cause the resource usage to remain constantly high. In the worst case scenario, the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up, and nodes will never learn about the current state of the world.

We expect that the performance will improve over time as we improve the code base, but it is not a focus. In general, we will never make the tradeoff to make things faster on the cost of less maintainable or readable code. We are a small team and have to optimise for maintainability.

Which database should I use?

We recommend the use of SQLite as database for headscale:

  • SQLite is simple to setup and easy to use
  • It scales well for all of headscale's use cases
  • Development and testing happens primarily on SQLite
  • PostgreSQL is still supported, but is considered to be in "maintenance mode"

The headscale project itself does not provide a tool to migrate from PostgreSQL to SQLite. Please have a look at the related tools documentation for migration tooling provided by the community.

The choice of database has little to no impact on the performance of the server, see Scaling / How many clients does Headscale support? for understanding how Headscale spends its resources.

Why is my reverse proxy not working with headscale?

We don't know. We don't use reverse proxies with headscale ourselves, so we don't have any experience with them. We have community documentation on how to configure various reverse proxies, and a dedicated "reverse-proxy-issues" channel on our Discord server where you can ask for help to the community.

Can I use headscale and tailscale on the same machine?

Running headscale on a machine that is also in the tailnet can cause problems with subnet routers, traffic relay nodes, and MagicDNS. It might work, but it is not supported.

Why do two nodes see each other in their status, even if an ACL allows traffic only in one direction?

A frequent use case is to allow traffic only from one node to another, but not the other way around. For example, the workstation of an administrator should be able to connect to all nodes but the nodes themselves shouldn't be able to connect back to the administrator's node. Why do all nodes see the administrator's workstation in the output of tailscale status?

This is essentially how Tailscale works. If traffic is allowed to flow in one direction, then both nodes see each other in their output of tailscale status. Traffic is still filtered according to the ACL, with the exception of tailscale ping which is always allowed in either direction.

See also https://tailscale.com/kb/1087/device-visibility.

My policy is stored in the database and Headscale refuses to start due to an invalid policy. How can I recover?

Headscale checks if the policy is valid during startup and refuses to start if it detects an error. The error message indicates which part of the policy is invalid. Follow these steps to fix your policy:

  • Dump the policy to a file: headscale policy get --bypass-grpc-and-access-database-directly > policy.json
  • Edit and fixup policy.json. Use the command headscale policy check --file policy.json to validate the policy.
  • Load the modified policy: headscale policy set --bypass-grpc-and-access-database-directly --file policy.json
  • Start Headscale as usual.

Full server configuration required

The above commands to get/set the policy require a complete server configuration file including database settings. A minimal config to control Headscale via remote CLI is not sufficient. You may use headscale -c /path/to/config.yaml to specify the path to an alternative configuration file.

How can I avoid to send logs to Tailscale Inc?

A Tailscale client collects logs about its operation and connection attempts with other clients and sends them to a central log service operated by Tailscale Inc.

Headscale, by default, instructs clients to disable log submission to the central log service. This configuration is applied by a client once it successfully connected with Headscale. See the configuration option logtail.enabled in the configuration file for details.

Alternatively, logging can also be disabled on the client side. This is independent of Headscale and opting out of client logging disables log submission early during client startup. The configuration is operating system specific and is usually achieved by setting the environment variable TS_NO_LOGS_NO_SUPPORT=true or by passing the flag --no-logs-no-support to tailscaled. See https://tailscale.com/kb/1011/log-mesh-traffic#opting-out-of-client-logging for details.

\ No newline at end of file diff --git a/development/about/features/index.html b/development/about/features/index.html index fc1f6e74..ca34580a 100644 --- a/development/about/features/index.html +++ b/development/about/features/index.html @@ -1 +1 @@ - Features - Headscale
Skip to content

Features

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. This page provides on overview of Headscale's feature and compatibility with the Tailscale control server:

\ No newline at end of file + Features - Headscale
Skip to content

Features

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. This page provides on overview of Headscale's feature and compatibility with the Tailscale control server:

\ No newline at end of file diff --git a/development/about/help/index.html b/development/about/help/index.html index 23d86193..801fd3e6 100644 --- a/development/about/help/index.html +++ b/development/about/help/index.html @@ -1 +1 @@ - Getting help - Headscale
Skip to content
\ No newline at end of file + Getting help - Headscale
Skip to content
\ No newline at end of file diff --git a/development/about/releases/index.html b/development/about/releases/index.html index 4617ee22..e03a20ac 100644 --- a/development/about/releases/index.html +++ b/development/about/releases/index.html @@ -1 +1 @@ - Releases - Headscale
Skip to content

Releases

All headscale releases are available on the GitHub release page. Those releases are available as binaries for various platforms and architectures, packages for Debian based systems and source code archives. Container images are available on Docker Hub and GitHub Container Registry.

An Atom/RSS feed of headscale releases is available here.

See the "announcements" channel on our Discord server for news about headscale.

\ No newline at end of file + Releases - Headscale
Skip to content

Releases

All headscale releases are available on the GitHub release page. Those releases are available as binaries for various platforms and architectures, packages for Debian based systems and source code archives. Container images are available on Docker Hub and GitHub Container Registry.

An Atom/RSS feed of headscale releases is available here.

See the "announcements" channel on our Discord server for news about headscale.

\ No newline at end of file diff --git a/development/about/sponsor/index.html b/development/about/sponsor/index.html index af27d825..9c9e601d 100644 --- a/development/about/sponsor/index.html +++ b/development/about/sponsor/index.html @@ -1 +1 @@ - Sponsor - Headscale
Skip to content

Sponsor

If you like to support the development of headscale, please consider a donation via ko-fi.com/headscale. Thank you!

\ No newline at end of file + Sponsor - Headscale
Skip to content

Sponsor

If you like to support the development of headscale, please consider a donation via ko-fi.com/headscale. Thank you!

\ No newline at end of file diff --git a/development/index.html b/development/index.html index 4a6e1c1b..12dd64f5 100644 --- a/development/index.html +++ b/development/index.html @@ -1 +1 @@ - Headscale
Skip to content

Welcome to headscale

Headscale is an open source, self-hosted implementation of the Tailscale control server.

This page contains the documentation for the latest version of headscale. Please also check our FAQ.

Join our Discord server for a chat and community support.

Design goal

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.

Supporting headscale

Please see Sponsor for more information.

Contributing

Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the Maintainers before being submitted.

Please see Contributing for more information.

About

Headscale is maintained by Kristoffer Dalby and Juan Font.

\ No newline at end of file + Headscale
Skip to content

Welcome to headscale

Headscale is an open source, self-hosted implementation of the Tailscale control server.

This page contains the documentation for the latest version of headscale. Please also check our FAQ.

Join our Discord server for a chat and community support.

Design goal

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.

Supporting headscale

Please see Sponsor for more information.

Contributing

Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the Maintainers before being submitted.

Please see Contributing for more information.

About

Headscale is maintained by Kristoffer Dalby and Juan Font.

\ No newline at end of file diff --git a/development/ref/acls/index.html b/development/ref/acls/index.html index 7c5969c0..19b5ed7d 100644 --- a/development/ref/acls/index.html +++ b/development/ref/acls/index.html @@ -1,4 +1,4 @@ - ACLs - Headscale
Skip to content

ACLs

Headscale implements the same policy ACLs as Tailscale.com, adapted to the self-hosted environment.

For instance, instead of referring to users when defining groups you must use users (which are the equivalent to user/logins in Tailscale.com).

Please check https://tailscale.com/kb/1018/acls/ for further information.

When using ACL's the User borders are no longer applied. All machines whichever the User have the ability to communicate with other hosts as long as the ACL's permits this exchange.

ACL Setup

To enable and configure ACLs in Headscale, you need to specify the path to your ACL policy file in the policy.path key in config.yaml.

Your ACL policy file must be formatted using huJSON.

Info on how these policies are written can be found here.

Please reload or restart Headscale after updating the ACL file. Headscale may be reloaded either via its systemd service (sudo systemctl reload headscale) or by sending a SIGHUP signal (sudo kill -HUP $(pidof headscale)) to the main process. Headscale logs the result of ACL policy processing after each reload.

Simple Examples