ScaleTail's quick start writes a tailnet auth key into a file inside the clone

The auth key goes into a file inside the working tree

The quick start is three steps. Generate an auth key in the Tailscale admin console, clone the repository and change into the directory of the service you want, then open the `.env` file in that directory and add your key after the line `TS_AUTHKEY=`, and bring the stack up:

``` bash git clone https://github.com/tailscale-dev/ScaleTail.git cd ScaleTail/services/YourDesiredService

bash docker compose up -d ```

The credential detail is the one to notice. The key goes into a file that lives inside a directory of a repository you just cloned, and an auth key is the thing that lets a machine join your tailnet. The page does not say the `.env` file is ignored, and the only ignore configuration visible is a `.gitignore` at the repository root whose contents are not shown.

The fix is procedural rather than technical, and it is worth doing before the first `git add` in that tree rather than after. Treat the key as a credential, scope it to a single node rather than a reusable enrollment key, give it an expiry, and if you need to commit anything in that directory check what your own ignore rules cover first. A Tailscale key is not a password to a single web login; it is authorisation to add a machine to a private network, and the difference matters when deciding how long to keep it valid.

The quick start produces a private name, and the public path arrives later

What the stack gives you, per the opening paragraph, is a URL with automatic HTTPS, with the example `https://application.tail-net.ts.net`. That form carries your tailnet name, which means the service is reachable by the devices on your network and not by the public internet. That is the Serve behaviour.

The contents list carries a section titled Tailscale Funnel vs. Tailscale Serve, with Funnel and Serve each given their own subsection, under a Tailscale Information heading. So the readme plans to explain the difference between the private path and the public one, and to give each its own treatment.

That ordering is the thing to be aware of. Someone following the quick start top to bottom gets a private service, which is the safe outcome, and the section explaining how to make something public is further down. For a catalogue of self-hosted dashboards, reverse proxies, DNS servers and a remote control server, that ordering is defensible, since the private case is the common one. It does mean the decision about exposure is made by omission rather than by instruction, and if you add stacks to the catalogue later it is worth deciding per service rather than setting a global default.

One entry exists to get past Cloudflare, which is a different kind of decision

The networking and security group includes an entry described as a proxy server to bypass Cloudflare and DDoS-GUARD protection. That is a materially different proposition from every other item in the list.

Everything else in the catalogue protects something. An ad blocker protects you from tracking. A DNS server and a reverse proxy change how traffic reaches your own machine. A remote control server is a tool you operate. The entry in question is aimed outward: its purpose is to get your requests past a protection mechanism that a third party has deliberately deployed, and the traffic it produces is directed at that third party's defences rather than at a service you own.

That framing is scope, not syntax. Running it against infrastructure you operate or have written permission to test is a different act from pointing it at someone else's site, and the project itself draws no line between the two, because a compose stack is a compose stack and the scope lives in the deployment.

If you take one entry from this catalogue on trust, make it that one. Read what it is for, decide whether the target is yours, and if it is not, leave it out. Nothing else in the list asks the question.

The networking category is a flat list with four DNS entries and two ad blockers

Fifteen entries share the networking and security heading, and they are not a taxonomy. Four of them concern DNS in some form: AdGuard Home, a DDNS updater that keeps A and AAAA records current, Pi-hole as a DNS sinkhole, and Technitium as a general DNS server. Two are ad blockers, AdGuard Home and Pi-hole, and the catalogue also carries a separate tool for syncing AdGuard Home configuration across instances.

Two are servers that terminate TLS, Caddy described as extensible and using TLS by default, and Traefik as a reverse proxy and load balancer for microservices. Then there is a vulnerability scanner, a network documentation and modelling tool, an OIDC provider that signs users in with passkeys, a remote control server, and the Cloudflare entry discussed above.

So picking from this group is a real decision with overlapping choices, not a matter of finding the one service you want. If your problem is ad blocking you have two candidates that differ in architecture, one being a full DNS server and the other a filtering forwarder that needs a resolver in front of it. If your problem is a hostname that follows your IP you have a DDNS updater that may or may not be needed depending on how you expose things. The flat table does not help you make those comparisons, which is what a per-service detail page would have to do.

Three of the fifteen entries are Tailscale device roles, not applications

The last three rows of the networking table are not services to install. They are descriptions of a device you already have:

- Tailscale App Connector Node, configured to act as an App connector node - Tailscale Exit Node, configured to act as an exit node - Tailscale Subnet Router Node, configured to act as a subnet router node

Each one is a role rather than a workload, each is described in the same Configure a device to act as wording, and each carries a Details link of the same shape as the applications above. So the same navigation covers two different things: a compose stack you bring up, and a setting you apply to a machine you own.

That is a reasonable thing to include, because all three are the natural next questions after someone has put a service on their tailnet, but it means the stack format is not uniform across the directory. A reader assuming every entry under `services/` is a compose file will find three that are not.

One small sign that the table is maintained by hand: the App Connector row reads a device to act as a App connector node, with the article wrong in front of the vowel. Along with a table of this size, that is the kind of detail that shows the list is edited directly rather than generated from a source of truth.

The contents promise nine categories and the page ends in the second one

The table of contents lists nine groups of services: networking and security, media and entertainment, productivity and collaboration, dashboards and visualization, development tools, monitoring and analytics, smart home, utilities, and food and wellness. After those it lists six more top-level sections, Tailscale Information with its three subsections, Tailscale Documentation, Contributors, Contributing, Star History and License.

The page shown reaches the first group in full and stops partway through the second, in the media table, at a row that begins and does not finish. So seven of the nine groups are not on it, and all six trailing sections are not either.

That is worth knowing before drawing a conclusion about scope. What is visible is a catalogue weighted toward infrastructure, which is what a Tailscale sidecar collection would plausibly be, but the unseen groups include development tools and monitoring, and a collection of that size is likely to have entries whose security posture differs from an ad blocker. The one thing visible about the presentation is that the contents is maintained by hand, complete down to anchor links with the section emoji in them, and a `.markdownlint.yml` at the repository root is what keeps that markdown consistent.

The only outside validation is one video that claims ten minutes

The section headed Featured by Tailscale contains one item. A presenter from the official Tailscale YouTube channel did a deep dive into ScaleTail, and the description says he walks through how to deploy a secure, private service in under ten minutes, with a link to the video.

That is the whole of the third-party assessment available on the page. It is a reasonable thing for a project to point at, and a walkthrough by someone from the vendor's own channel is better than nothing, but it is a single video rather than a set of independent reports, and the ten minutes is the presenter's figure for his path through the material rather than a measured property of the stacks.

What the project offers instead is the stacks themselves, and that is the right thing to lean on. Each service has its own Details page, and a compose file is readable. If you want to know what a given stack does, the answer is in the directory rather than in a review.

The repository shape supports that reading. Alongside the readme there is a `services/` directory, a separate `templates/` directory that presumably holds the starting point for a new one, a `documentation/` directory, an `images/` directory, `AGENTS.md`, `CONTRIBUTING.md` and a `LICENSE`. And there are no GitHub releases, so a stack has no version: what you run is whatever commit you cloned.

Editorial conclusion

ScaleTail is a good fit if you run several self-hosted services and want each of them on the tailnet with a proper certificate, and you are willing to read each stack before starting it, because the catalogue is a convenience wrapper rather than an audit. Four things to check. The credential: step three of the quick start has you write a Tailscale auth key into the `.env` file of a directory you have just cloned, and the page says nothing about that file being ignored, so confirm your ignore rules before you ever stage anything in that tree, and scope the key to a single node with a short expiry rather than making it a reusable enrollment credential. The exposure model: what the quick start produces is a tailnet name such as `https://application.tail-net.ts.net`, which is private to your network, while the readme carries a later section separating that from Funnel, which is the public path, so decide per service rather than enabling it once and forgetting. The catalogue: about fifteen entries in the networking and security group include two ad blockers, four DNS-adjacent tools, two reverse proxies, a vulnerability scanner with its own licensing terms, and a remote control server, so several stacks grant far more capability than a photo library needs. And one entry, Flaresolverr, exists to get past Cloudflare and DDoS-GUARD protection, which is a different kind of decision from hosting a dashboard, and it is the one to think hardest about, because the traffic it produces is aimed at a third party's defences rather than at your own service.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. tailscale-dev/ScaleTail on GitHub