No no, sorry. I mean can I still have all my network traffic go through some VPN service (mine or a providers) while Tailscale is activated?

Tailscale just partnered with Mullvad so this works out of the box for that setup: https://tailscale.com/blog/mullvad-integration/

For others, it’s a “yes on paper” situation. It will probably often not work out of the box, but it seems likely to be possible as an advanced configuration. At the end of the line of possibilities, it would definitely be possible to set up a couple of docker containers as one-armed routers, one with your VPN and one with Tailscale as an exit node. Then they can each have their own networking stack and you can set up your own routes and DNS delegating only the necessary bits to each one. That’s a pretty advanced setup and you may not have the knowhow for it, but it demonstrates what’s possible.

To a first approximation, Tailscale/Headscale don’t route and traffic.

Ah, well damn. Is there a way to achieve this while using Tailscale as well, or is that even recommended?

Is there a way to achieve what? Force tailscale to route all traffic through the DERP servers? I don’t know, and I don’t know why you’d want to. When my laptop is at home on the same network as my file-server, I certainly don’t want tailscale sending filserver traffic out to my Headscale server on the Internet just to download it back to my laptop on the same network it came from. I want NAT traversal to allow my laptop and file-server to negotiate the most efficient network path that works for them… whether that’s within my home lab when I’m there, across the internet when I’m traveling, or routing through the DERP server when no other option works.

OpenVPN or vanilla Wireguard are commonly setup with simple hub-and-spoke routing topologies that send all VPN traffic through “the VPN server”, but this is generally slower path than a direct connection. It might be imperceptibly slower over the Internet, but it will be MUCH slower than the local network unless you do some split-dns shenanigans to special-case the local-network scenario. With Tailscale, it all more or less works the same wherever you are which is a big benefit. Of course excepting if you have a true multigigabit network at home and the encryption overhead slows you down… Wireguard is pretty fast though and not a problematic throughout limiter for the vast majority of cases.

Have a read through https://tailscale.com/blog/how-nat-traversal-works/

You, and many commenters are pretty confused about out tailscale/Headscale work.

1. To a first approximation, Tailscale/Headscale don’t route and traffic. They perform NAT traversal and data flows directly between nodes on the tailnet, without traversing Headscale/Tailscale directly.
2. If NAT traversal fails badly enough, it’s POSSIBLE that bulk traffic can flow through the headscale/tailscale DERP nodes… but that’s an unusual scenario.
3. You probably can’t run Headscale from your home network and have it perform the NAT traversal functions correctly. Of course, I can’t know that for sure because I don’t know anything about your ISP… but home ISPs preventing Headscale from doing it’s NAT traversal job are the norm… one would be pleasantly surprised to find that a home network can do that properly.
4. Are younreally expecting 10gb/s speeds over your encrypted links? I don’t want to say it’s impossible, people do it… but you’d generally only expect to see this on fairly burly servers that are properly configured. Tailscale just in April bragged about hitting 10gb speeds with recent optimizations: https://tailscale.com/blog/more-throughput/ and on home hardware with novice configd I’d generally expect to see roughly more like single gigabit.

Tailscale is out, unfortunately. Because the server also runs Plex and I need to use it with Chromecast on remote access…

I rather suspect you already understand this, but for anyone following along… Tailscale can be combined with other networking techniques as well. So one could:

• Access Plex from a Chromecast on your home network using your physical IP, and on your tailnet using the overlay IP.
• Or one could have some services exposed publicly and others exposed on the tailnet. So Immich could be on the tailnet while Plex is exposed differently.

It’s not an all or nothing proposition, but of course the more networking components you have the more complicated everything gets. If one can simplify, it’s often well worth doing so.

Good luck, however you approach it.

So for something like Jellyfin that you are sharing to multiple people you would suggest a VPS running a reverse proxy instead of using DDNS and port forwarding to expose your home IP?

I run my Jellyfin on Tailscale and don’t expose it directly to the internet. This limits remote access to my own devices, or the devices of those I’m willing to help install and configure tailscale on. I don’t really trust Jellyfin on the public internet though. It’s both a bit buggy, which doesn’t bode well for security posture… and also a misconfiguration that exposes your content could generate a lot of copyright liability even if it’s all legitimately licensed since you’re not allowed to redistribute it.

But if you do want it publicly accessible there isn’t a hoge difference between a VPS proxying and a dynamic DNS setup. I have a VPS and like it, but there’s nothing I do with it that couldn’t be done with Cloudflare tunnel or dyndns.

What VPS would you recommend? I would prefer to self host, but if that is too large of a security concern I think there is a real argument for a VPS.

I use linode, or what used to be linode before it was acquired by Akamai. Vultr and Digitalocean are probably what I’d look to if I got dissatisfied. There’s a lot of good options available. I don’t see a VPS proxy as a security improvement over Cloudflare tunnel or dyndns though. Tailscale is the security improvement that matters to me, by removing public internet access to a service entirely, while lettinge continue to use it from my devices.

Do I need to set up NGINX on a VPS (or similar cloud based server) to send the queries to my home box?

A proxy on a VPS is one way to do this, but not the only way and not necessarily the best one… depending on your goals.

• You can also use port-forwarding and dyndns to just expose the port off your home-ip. If your ISP is sucky, this may not work though.
• You can also use Cloudflare’s free tunneling product, which is basically a hosted proxy that acts like a super port-forward that bypasses sucky ISP restrictions.
• If you want to access Immich yourself from your own devices but don’t need to make it available to (many) others on devices you don’t control, I like and use tailscale the best. The advantage of tailscale is that Immich remains on a private network, not directly scannable from the internet. If there’s a preauth exploit published and you don’t pay attention to update promptly, scanners WILL exploit your Immich instance with internet-exposed techniques… whereas tailscale allows you to access services that internet scanners cannot connect to, which is a nice safety net.

Do I need to purchase a domain (randomblahblah.xyz) to use as the main access route from outside my house?

Not for tailscale, and I don’t think for Cloudflare tunnel. Yes for a VPS proxy.

I’ve run a VPS for a long while and use multiple techniques for different services.

• Some services I run directly on the VPS because it’s simple and I want them to be truly publicly accessible.
• Other services I run on a bigger server at home and proxy through the VPS because although I want them to be publicly accessible, they require more resources than my VPS has available. When I get around to installing Immich, there’s a decent chance it will go into this category.
• Still other services, I run wherever and attach them to my tailnet. These I access myself on my own devices (or maybe invite a handful of trusted people into my tailnet), but aren’t visible to the public internet. If I decide not to use immich’s shared gallery features (and so don’t need it publicly accessible) or decide I don’t trust it security-wise… it will go here instead of the proxy-by-vps category.

I use k8s at work and have built a k8s cluster in my homelab… but I did not like it. I tore it down, and currently using podman, and don’t think I would go back to k8s (though I would definitely use docker as an alternative to podman and would probably even recommend it over podman for beginners even though I’ve settled on podman for myself).

1. K8s itself is quite resource-consuming, especially on ram. My homelab is built on old/junk hardware from retired workstations. I don’t want the kubelet itself sucking up half my ram. Things like k3s help with this considerably, but that’s not quite precisely k8s either. If I’m going to start trimming off the parts of k8s I don’t need, I end up going all the way to single-node podman/docker… not the halfway point that is k3s.
2. If you don’t use hostNetworking, the k8s model of traffic routes only with the cluster except for egress is all pure overhead. It’s totally necessary with you have a thousand engineers slinging services around your cluster, but there’s no benefit to this level fo rigor in service management in a homelab. Here again, the networking in podman/docker is more straightforward and maps better to the stuff I want to do in my homelab.
3. Podman accepts a subset of k8s resource-yaml as a docker-compose-like config interface. This lets me use my familiarity with k8s configs iny podman setup.

Overall, the simplicity and lightweight resource consumption of podman/docker are are what I value at home. The extra layers of abstraction and constraints k8s employs are valuable at work, where we have a lot of machines and alot of people that must coordinate effectively… but I don’t have those problems at home and the overhead (compute overhead, conceptual overhead, and config-overhesd) of k8s’ solutions to them is annoying there.

Nutbutter sort of covered it.

• Tailscale creates a virtual network.
• That network can be (and is by default) private in that no one can join that you don’t allow, and in that respect it’s similar to your home network. You can join your laptop, desktop, and phone to your tailnet… but probably you cannot join your Chromecast or smart-television (they don’t publish tsilscale clients for these devices).
• If you configure Jellyfin to listen on your tailnet and not on the Internet… then you can access Jellyfin from anywhere using a device that is connected to your tailnet, but attackers on the Internet cannot access Jellyfin without first accessing your tailnet, which is hard to do.

The security/convenience tradeoff of tailscale is pretty good if you want to access a service from anywhere, but only from your own devices and only from supported operating systems (Linux, windows, OSX, android… not sure about iOS). It is another networking layer, which can be mind-bending… but as much as such a layer can be easy to use… tailscale is as easy as any of them.

However, Tailscale’s backend is not open-source. They may not log all the data passed through, but they certainly can look at it.

This see sentence is nonsense though.

• Tailscale is end to end encrypted, tailscale cannot quietly see your traffic.
• Tailscale COULD, by default, surreptitiously join a node to your tailnet. If you’re super paranoid, they provide a way to disable this but it makes tailscale much less convenient to use: https://tailscale.com/kb/1226/tailnet-lock/
• Tailscale is phenomenally transparent about security and has WAY higher standards than self-hosters: https://tailscale.com/security/.
• Tailscale clients are open source, and they employ the author of Headscale an open source implementation of the Tailscale control protocols.

There is very little to fear from Tailscale as a provider, and they support the headscale project if you want to go that route (which I do… but not because I am concerned about Tailscale’s integrity or security posture).

This is a great approach, but I find myself not trusting Jellyfin’s preauth security posture. I’m just too concerned about a remote unauthenticated exploit that 2fa does nothing to prevent.

As a result, I’m much happier having Jellyfin access gated behind tailscale or something similar, at which point brute force attacks against Jellyfin directly become impossible in normal operation and I don’t sweat 2fa much anymore. This is also 100% client compatible as tailscale is transparent to the client, and also protects against brute force vs Jellyfin as direct network communication with Jellyfin isn’t possible. And of course, Tailscale has a very tightly controlled preauth attack surface… essentially none of you use the free/commercial tailscale and even self-hosting headscale I’m much more inclined to trust their code as being security-concscious than Jellyfin’s.

Fair enough, sound like you have a well considered use case for Kuma specifically. Good luck, I don’t have much to offer on your OP question.

This isn’t exactly an answer to your question, but an alternative monitoring architecture that elides this problem entirely is to run netdata on each server you run.

• It appears to collect WAY more useful data than uptime Kuma, and requires basically no config. It also collects data on docker containers running on the server so you automatically get per-service metrics as well.
• Health probes for several protocols including ping and http can be custom-defined in config-files if you want that.
• There’s no cross server config or discovery required, it just collects data from the system it’s running on (though health probes can hit remote systems if you wish).
• If any individual or collection of services is down, I see it immediately in their metrics.
• If the server itself is down, it’s obvious and I don’t need a monitoring system to show a red streak for me to know. I’ve never wasted more than minute differentiating between a broken service and a broken server.

This approach needs no external monitoring hosts. It’s not as elegant as a remote monitoring host that shows everything from a third-party perspective, but that also has the benefit of not false-positiving because the monitoring host went down or lost its network path to the monitored host… Netdata can always see what’s happening because it’s right there when it happens.

Thanks for the suggestion, but sync seems to be working ok… at least on the read side. I was able to verify the pre-existing good state and the bad state afterward from multiple clients. If sync played into it, it must have been on a write somehow.

The Foundry VTT community frequently uses video conferencing for tabletop roleplaying games and initially Jitsi was the recommended self-hosted video option, but the community has since moved on and now recommends https://livekit.io/. I didn’t set up either and don’t have deep insights into what drove the shift, but it’s an interesting data point around a community that tried both shifting focus away from Jitsi.

I can’t remember if it’s enabled by default or not, but it’s easy enough to enable pprof and get a helpful performance profile from /debug/pprof. See https://caddy.community/t/hangs-on-reload/12010/18 for an example.

I’ve found that even being unfamiliar with the codebase, it’s often pretty easy to identify what part of the call stack is being slow and file a very useful performance but report in GitHub. Check out the profile and see if it leads to any obvious conclusions about why domains are so much slower. There may be some function that’s trivial to cache the results of that brings things back to the expected performance.

is it worth starting out with podman or is this just some job requirement and docker is perfectly fine for us hobbyists

I’m doing this in my homelab, but I am a pro and so time spent learning arcane details of container ecosystems is not precisely wasted time for me. But I’m not doing it directly for some particular professional requirement, it’s more curiosity.

Based on my experience, I don’t think I could honestly recommend podman right now for a beginner. The people that tend to be most interested in podman tend to think:

• The best days of docker are behind it. The company hasn’t achieved financial success and are going to make it worse over time to pressure companies into paying them. We’ve seen the start of this with docker-desktop but I’m predicting it will continue and escalate.
• Docker was the first really successful container system and is very monolithic and full of questionable technical decisions. Improving it will be hard because of its success, and also because its monolithic nature means that many changes will bottleneck at docker the company, who as noted is not incentivized to make its open source stuff “too good” such that companies use it without paying.

Podman is more modular, is supported by more successful and stable companies can have revenue strategies that don’t require them to monetize podman specifically to death, and the individual pieces are small enough to be built and supported by individuals and non-commercial teams if necessary. So I’m sort of betting that over time podman will gain more traction and am willing to invest in learning my way through some bumps in the road as that happens. For beginners, I think you’ll know it’s time to consider a switch when projects start to ship podman configs instead of docker-compose configs. Then you’ll know that those devs think that supporting podman deployments will give them less headaches than supporting docker deployments and we’re reaching the inflection point where podman is starting to “win” and legit be easier/better. Right now I’m pretty clearly swimming upstream and I’m ok with that.

But relating back to OP’s question, although my usage of podman is a bit bleeding edge… it still illustrates the kind of problems every self-hoster hits and how it’s necessary to break those problems down into smaller parts to solve them yourself. It’s just not realistic to expect every self-hosting scenario to be fully tutorialized. Tutorials help us understand how the pieces fit together, but when things go wrong we have to understand the pieces and troubleshoot them directly rather than expect the tutorial to dive into fractally complex subject in easy/brief overviews but simultaneously dive into infinitely many edge-cases in depth.

I acknowledge it’s all surely basic but I’m not sure where to find a comprehensive source of learning instead of googling bits and pieces.

I think a challenge you are likely to run into is that self-hosting many services really ISN’T basic, and there simply aren’t comprehensive sources… and really can’t be. It’s too varied and complex. Every network environment is different, and every network environment is so complex that it takes a networking expert to understand. No tutorial can cover all the possibilities, or even help you figure out what scenario you’re in.

As an example, I’m currently migrating from docker-compose to podman-kube-play for my container management. I’m a a professional engineer who works with containers every day, and I’ve spent the better part of a week trying to get my first non-trivial container to run.

• I’ve had to read tutorials to see how to get started.
• I’ve had to read podman docs to see what k8s config options are supported.
• I’ve had to read bug reports and examples from people using podman to see how specific features get strung together for complex use-cases like mine.
• Even after getting many things right, DNS resolution didn’t work in my container. I spent many hours researching and found nothing. I finally had to start installing debugging tools like dig and nmap in my container to find that I couldn’t speak to the DNS server at all. I eventually found firewall logs showing that UFW was blocking the traffic from the container to the DNS server. UFW has nothing to do with Podman. Arch and Fedora users would not have been affected by this issue. Ubuntu users like me still wouldn’t have been affected if they were using host-networking or rootless podman. My specific environment and use-case was affected.

There is simply no single resource on the internet addressing my personal scenario. To get to the bottom of it, I had to know enough about podman, k8s, DNS, networking, firewalls, UFW specifically, where interesting data on my system tends to get logged, and enough about “normal” logs to sift through the garbage and find the logs that lead me to a solution.

So I recommend switching your perspective. Stop looking for a one-stop-shop that doesn’t exist. Instead, try to learn when the thing you’re trying to do is really 5 different things lashed together with duct tape. Then start deep-diving on each piece until you know enough about that thing to relate it to your specific environment and move on to the next thing. This is time consuming, especially as you’re getting started… but it’s fractally deep and remains time consuming forever as you continue to learn new things and aspire to do more complicated stuff. This breaking down of complex topics into a series of simpler (but not necessarily simple) topics is the hallmark of every successful engineer I’ve ever met.

A Lemmy server primarily does two kinds of work:

• Serve browse traffic: This is what you’re familiar with, when you view your post feed or a single post, the server has to fetch those posts or comments from its database and send them to you. The resources required to do so depend on the total number of browse requests the server handles… roughly num_users * num_feed_refreshes_or_post_views_per_user_per_minute. If a server has a lot of users that view a lot of stuff, splitting some of them off to a second server (or just stopping signups) will help.
• Federated replication: This is what copies posts and comments from the server that hosts the community to the server that hosts your account, and what enables your account server to bear the browse load for communities hosted on this server. The resources required to do this work are roughly proportional to the total number of federation messages sent, or number_of_federated_peer_serverd * number_of_subscribed_communities_per_server * number_of_posts_comments_votes_edits_etc_per_community.

What you may see here is that federation replication workload scales with the number of instances in the threadiverse and browse workload scales with the number of users per instance. This leads to a goldilocks problem. Ideally, you want a medium number of servers that each have a medium number of subscribers. Obviously no real world network scales in this ideal way, but some guidelines emerge:

• Single user instances are probably only a net win if the user is very active. If you read every post your instance subscribes to then maybe your browse load is bigger than your instance’s federation load… but if you log in once a month and view 1% of the posts replicated to your instance… it’s still generating federation workload while you’re asleep for posts you’ll never read.
• Single-user instances using scripts that mass subscribe to thousands of communities, while they make your all feed lively… make you a pretty terrible fediverse citizen. Your instance is now generating the federation load of a 5k user instance to copy posts and comments you’ll never read. BTW, your instance publicly serves copies of all the posts you subscribe to. So if one of these scripts subs porn, piracy, or hate speech communities on poorly admin’ed instances, it may be creating legal liability for you depending on your jurisdiction. Also, federated replication is pretty broky right now: https://github.com/LemmyNet/lemmy/issues/3101 (this recently got marked resolved but I continue to see replication issues daily and I expect similar but perhaps more targeted follow ups.to be filed soon)
• Having an account on a Very Big Instance like lemmy.world or lemmy.ml is a bit of a personal risk. Those instances will always find the limits of both browse and federation scaling first because they have lots of active users and also lots of active communities that are widely subscribed by other instances. This will make them a bit unreliable as they’re at the tip of the efforts to fix scaling constraints.

I posted a comparison a short while ago: https://lemmy.world/post/1452988

I recently decided on headscale as a coordination server with tailscale apps/clients for my setup. My rationale was:

• Tailscale seems to be dominating adoption. This isn’t a technical consideration but it often correlates with project velocity going forward.
• Headscale the self-hosted server is unofficially but decently supported by tailscale the company. They employ the dev and don’t seem to be trying to kill the project or mess with it much. It includes most features useful to selfhosted installs, but reserves multi-network setups as the domain of the official tailscale coordination server which strikes me as a pretty reasonable way to segment the market.
• Tailscale has great client coverage for Linux, windows, Mac, android, and iOS.
• I didn’t do a point by point feature comparison, but my sense was that tailscale/headscale meet or beat the featuresets of other projects, so I didn’t see any technical reasons to buck against community momentum.

The full firehose of the lemmyverse will grow your DB by about 2GB per day, plus an additional 8GB per day in thumbnails. And the rate is growing frantically. It’s not necessarily trivial, depending on how much you subscribe to.

!test@lemmy.ml is for test posts, this community is for discussion of self-hosting.