Selfhosted

@observantTrapezium

I just saw your other reply on Lemmy regarding Headscale.

Headscale should already solve that use case without putting mTLS in front of every service.

By default, a Headscale tailnet is rather permissive, but you can load a policy and use Grants (or ACLs, though Grants are the preferred direction) to explicitly allow only the connections you want. A phone does not need access to “the whole tailnet” just because it is enrolled.

For example, each user/device group could be allowed to reach only:

• the Immich host on its HTTPS port;
• the CalDAV/CardDAV host on 443;
• optionally the Matrix client endpoint on 443;

…and nothing else. No SSH, no databases, no admin UIs, no access to other tailnet nodes. Start with an empty grants policy — which denies all tailnet traffic — then add narrowly scoped allow rules for the relevant source devices and service destinations.

That also means the client can simply connect when it needs those services; it does not need broad, permanent network access merely because the Headscale app is installed. And if a device is lost, removing that node from Headscale cuts off its network access immediately.

So I would still favour: private services behind Headscale plus a deny-by-default policy, instead of managing a separate mTLS PKI for several native mobile apps. The latter is viable, but it is solving device/network admission at the application TLS layer when you already operate a tool designed to do it at the network layer. Headscale explicitly supports access control policies for restricting traffic between nodes, and policies can deny all traffic by default until specific access is granted.