The unfortunate reality is that some people will buy anything that expires, on the remote chance someone might be interested. If they’re set on doing that there’s nothing you can do, they will grab it and block it for at least one more year.

IMHO the best thing you can do is nothing. I mean nothing beyond discreetly checking the domain state in whois. Don’t inquire explicitly about the domain. Don’t use the WHOIS form on websites you don’t trust to exploit such queries into grabbing domains themselves.

You can use whois from the command line (best way). Alternatively, the TLD registry will have a WHOIS form on their official website.

If you don’t generate any apparent interest they will eventually let the domain lapse. Check back a year from now.

The problem is that the main container can (and usually does) rely on other layers, and you may need to pull updates for those too. Updating one app can take 5-10 individual pulls.

What does “old network” and “new network” mean? What are they, LAN setup? Docker setup? Describe them better (netmasks, routing etc.)

A self-hosting server does not necessarily crunch data and it doesn’t have to have loud fans or use lots of power. It can idle in the 15-20W range with an Intel CPU and if you put the HDDs on standby when idle.

Seafile is a file platform that’s more in line with what you mean. It can do sync but also sharing and collaborative editing.

I’m using InfCloud, it has support for events, tasks and contacts so it pairs perfectly with Radicale (which is also what I use). It doesn’t look amazing I’ll be honest and it lacks some features but it works fine.

Here’s my docker compose:

services:
  infcloud:
    image: ckulka/infcloud:0.13.1
    container_name: infcloud
    depends_on:
      - php
    ports:
      - "5233:80/tcp"
    volumes:
      - "infcloud:/usr/share/nginx/infcloud"
      - "./data/config.js:/usr/share/nginx/infcloud/config.js:ro"
    restart: always
  php:
    image: php:7.3-fpm-alpine
    container_name: infcloud-php
    volumes:
      - "infcloud:/usr/share/nginx/infcloud:ro"
    restart: always

volumes:
  infcloud:

Run it without mapping config.js first and copy it from the container, edit it on the host, then map the volume and reprovision the container. You have to find the section globalNetworkCheckSettings and add a href: entry that points to your radicale host, for example href: "http://192.168.1.1:5232".

Another essential setting is to edit the Radicale config file and add the following section:

[headers]
Access-Control-Allow-Origin = http://192.168.1.1:5233
Access-Control-Allow-Methods = GET, POST, OPTIONS, PROPFIND, PROPPATCH, REPORT, PUT, MOVE, DELETE, LOCK, UNLOCK
Access-Control-Allow-Headers = User-Agent, Authorization, Content-type, Depth, If-match, If-None-Match, Lock-Token, Timeout, Destination, Overwrite, Prefer, X
Access-Control-Expose-Headers = Etag, Preference-Applied

The -Allow-Origin host and port must match the URL where you access InfCloud in the browser.

If you use a reverse proxy and you put Radicale / InfCloud behind domain names you can use the domain names in config.js and config. As long as InfCloud knows where to find Radicale, and Radicale knows where InfCloud comes.

Check how you get your data out.

First of all, have you stacking the public and private subdomains on the same base domain? It’s what I do at the moment, I have external services on *.mydomain.com and internal services on *.home.mydomain.com.

You can get one wildcard cert for *.mydomain.com and one for *.local.mydomain.com so all your services are protected by TLS, both inside and outside your LAN. You also get to manage all of them identically in the same place (Traefik in your case).

You do NOT have to define any of these domains in DNS in order to pass the Let’s Encrypt DNS challenge. LE doesn’t care what you’ll put in DNS, just wants to verify the domain is yours. So just giving it an API token with access to mydomain.com is enough. (If your DNS provider doesn’t offer API check out this list of providers.)

It’s important to understand that the reverse proxy doesn’t actually care about DNS and whether those domains resolve, it just looks for the domain in the HTTP headers. So you can define those domains anywhere you want. You have several options:

1. For the public subdomains you need to define them in your public DNS, so you can resolve them from anywhere on the Internet. Let’s say your server IP is 1.2.3.4. You define an A record pointing mydomain.com to 1.2.3.4, and a wildcard CNAME that points *.mydomain.com to mydomain.com. Now all the subdomains directly under mydomain.com resolve to that IP.
2. For the private subdomains you have several options:
   • Best approach is to do the same as above for *.home.mydomain.com, but do in on the private DNS used on your LAN, and point to the LAN IP of your server instead of your public IP.
   • If for whatever reason your LAN DNS can’t do this (or you can’t control it) you can put the entries in the public DNS. It’s a bit unorthodox putting private LAN stuff in a public DNS but it works.
   • You can even define sub.home.mydomain.net names in the local hosts file on your PC, if you only need to access them from the PC. You only need to trick your browser into resolving them so it will put them in the HTTP headers, the reverse proxy doesn’t care.

An important note about security, because someone has already mentioned this in another comment. There are malware bots that keep scanning domains and IPs and ports looking for apps, and then they try exploits to try to break in. Having services exposed publicly without an extra authentication in front can make you vulnerable to these bots. It’s not a question of if they’ll find your app, it’s a question of when. You can mitigate the risk by blacklisting IPs in your router, for example you can blacklist anything that’s not coming from your country, but that only reduces the surface, does not completely eliminate the threat.

The bots also scan issued Let’s Encrypt certificates (which are a matter of public record) which is why it’s important to only get wildcard (*.mydomain.com) certificates, never explicit subdomains (sub.mydomain.com). It’s also important to never link to your services from web pages or share them with others.

Assuming you keep the subdomains for yourself, and you get a wildcard cert, and you use a reverse proxy, and you make the domain not easy to guess (don’t use something like “calendar.mydomain.com”) then you can very effectively prevent bots from getting to your services. That’s because the reverse proxy won’t honor requests if it doesn’t recognize the full domain name. So the subdomain can act as a sort of access key if you make it long enough (63 chars limit per subdomain, 255 max limit on the entire domain). That’s a pretty respectable key length… as long as you don’t publish it anywhere (only define it on the reverse proxy and your phone for example).

Borg Backup. It can work locally or over network. Takes snapshots of the files you give it. Performs deduplication, compression and optionally encryption. You can check the integrity of the backups and repair them. There’s a very simple to use GUI for it called Pika Backup to get you started.

Is there a reason to expose your services to the whole internet? That’s what CF tunnels and Tailscale Funnel do.

I can’t really recommend either of them, Funnel forces you to use a .ts.net subdomain you can’t use your own domain. CF allows it but forces you to use their DNS service. Both CF and Tailscale play MITM with your HTTPS connection, meaning they decrypt and reencrypt it on the fly, meaning they are able to look at your unencrypted traffic.

If you really must expose your services publicly then get a cheap VPS, point your domain A and AAAA records at its public IPs, make a tunnel from your server to the VPS, and forward connections to port 443 on the VPS public interface through the tunnel to the reverse HTTP proxy running on your server (with mandatory TLS encryption and Let’s Encrypt certificates for your domain).

This way you get an unbroken TLS connection all the way through, with nobody in the middle.

The tunnel that you use between your server and the VPS can work behind CGNAT because it’s outgoing.

Technically the tunnel doesn’t necessarily need to be encrypted because it will only carry TLS connections anyway, but then you have to deal with authorization. It’s probably simplest to do an SSH tunnel.

When you “cast” from the phone to the Chromecast, what happens it that the phone gives the Chromecast an URL where it can find the stream to play. The phone can read that stream because it’s connected to the Tailscale VPN. The Chromecast isn’t, so the stream URL is inaccessible to it. You see the Jellyfin logo because that’s a feature of casting (the app on the phone gives the Chromecast a logo to show).

There’s no point in announcing the subnet from your laptop, because your laptop is not a router for the local LAN. You can use this to reach local LAN devices from remote Tailscale nodes but not the other way around.

Some possible solutions:

1. You enable the hotspot feature on the phone while connected to Tailscale, and connect the Chromecast to the wifi of the phone. But the stream will consume the cellular connection, because you’re using the phone’s wifi for the hotspot (the phone only has one wifi interface so it cannot use it both to connect to the local LAN and for hotspot).
2. If you connect the local laptop to the router with a wired connection you can use its wifi as hotspot, connect the laptop to Tailscale, connect the Chromecast to the laptop hotspot, and the stream will arrive over the local connection.
3. You can try to install Tailscale on the router, if it runs OpenWRT or something similar, and if it has enough storage space (the Tailscale packages are kinda large). If you announce the subnet from the router then it will work as intended and all the devices on the local LAN will be able to “see” the remote laptop.
4. If you’re using nginx as reverse proxy with TLS certificates for the remote Jellyfin you can try this: expose it to the internet without Tailscale and use nginx-ip-whitelister to temporarily allow access from your local LAN’s public IP. All devices in the local LAN will see the remote Jellyfin. But read the warnings on the project page, it’s not as secure as a VPN. And of course “expose jellyfin to the internet” is not as simple as it sounds (you need a domain, you need to get Let’s Encrypt certs, a public IP, a port forward etc.)

rsync -avxH will copy the files between drives.

You can simply mount the new drive in the same place as the old one after the copy, that way you don’t have to change any paths.

I haven’t tried this yet I’ve only read about it. You can add an authenticator app + reverse proxy in front of HTTP services like Jellyfin. The combination Authelia + Traefik is often mentioned. When the person tries to open up the Jellyfin web app they see an Authelia screen asking for username + password, which when provided goes away and whitelists their public IP for a configurable time period. They don’t have to input the user+pass on the TV, they can visit the Jellyfin web app on their phone or laptop, then it will work for all devices behind that public IP. This would allow things like TV sets or Chromecast to work transparently.

I’m waiting for the day Google Recaptcha will ask me “is that traffic light red?” and after a couple of seconds “hurry up, I’m approaching the intersection!”

If by “easy” you mean someone else already spent 5 years and a nice chunk of cash training a model for it, which you get to use. And if you accept that it will not be accurate across all possible species and environments, only very specific subsets.