NPM is awesome until you have a weird error that the web GUI does not give a hint about the problem. Used it for years at this point and wouldn’t consider anything else at this point. It just works and is super simple.

+1 for NPM! Used to even do things manually, but I’m too lazy for that and NPM fulfils nearly all my use cases lol

Do you serve things to a public? Like a website? Because unless you’re serving a public, that’s dumb to do… and you really don’t understand the purpose of it.

If all you wanted was the ability to access services remotely, then you should have just created a WireGuard tunnel and set your phone/laptop/whatever to auto connect through it as soon as you drop your home Wifi.

I moved from swag to caddy and I’m glad i did. So much more simple.

I love Caddy. So easy to configure, and the automatic SSL is almost always what I need.

Pretty much I have caddy on a VPS that’s pointing to my internal IP using a tailscale tunnel. You are still exposing the web gui to the Internet so I just changed authentication to OAuth to mitigate since risk. There is still a possibility of attacks via zero days, but my immich is on a VM and I’m creating firewall rules to just allow certain ports out.

I’ll try to ELI5, if there’s something you don’t understand ask me.

Op has a home server where he’s running immich, that’s only accessible when he’s at home via the IP, so something like http://192.168.0.3:3000/, so he installed Tailscale on that server. Tailscale is a VPN (Virtual Private Network) that allows you to connect to your stuff remotely, it’s a nice way to do it because it is P2P (peer-to-peer) which means that in theory only he can access that network, whereas if he were using one of the many VPNs people use for other reasons, other people on the same VPN could access his server.

Ok, so now he can access his immich instance away from home, all he has to do is connect to the VPN on his phone or laptop and he’ll be able to access it with something like http://my_server:3000 since Tailscale adds a DNS (Domain Name System) which resolves the hostnames to whatever IP they have on the Tailscale network.

But if you want to give your family access it’s hard to explain to them that they need to connect to this VPN, so he rented a VPS (Virtual Private Server) on some company like DigitalOcean or Vultr and connected that machine to the Tailscale network. He probably also got a domain name from somewhere like namecheap, and pointed that domain name to his VPS. Só now he can access his VPS by using ssh user@myserver.com. Now all he needs to do is have something on the VPS which redirects everything that comes to a certain address into the Tailscale machine, Caddy is a nice way to do this, but the more traditional approach is ngnix, so if he puts Caddy on that VPS a config like this:

immich.myserver.com {
    handle {
        reverse_proxy my_server.tailscale.network.name:3000
    }
}

Then any requests that come to https://immich.myserver.com/ will get redirected to the home server via Tailscale.

It is a really nice setup, plus OP also added authentication and some other stuff to make it a bit more secure against attacks directly on immich.

It does a couple things. It’s one service that routes requests to multiple services. So if you have radarr, sonarr, etc., you can put a reverse proxy in front and use the same ip-port to connect to all, and the proxy routes the request to the service by hostname.

If you have multiple instances of the same service for HA, it can load balance between them (though this is unlikely for a homelab).

Personally I run all my services through docker and put traefik in front, so that I don’t have to keep track of ports. It’s all by name.

It’s also nice because traefik handles HTTPS termination, so it automatically gets certs for each name, and the backing service never needs to worry about it (it’s http on the backend, but all that traffic is internal).

I don’t even bother with the internal DNS server. I just set my A records in Cloudflare to point to the private IPs

I want to be able to upload/download/share my photos from anywhere in the world without using a VPN. Additionally, this satisfies the wife requirement. It works in the background without her needing her to turn on the VPN. I don’t want her to keep asking me how do I turn on the VPN? If it’s just me, then no issue, I’ll use a VPN.

Opening it up lets you use it from devices that aren’t on tailscale, or for friends and family. I have the same idea with Nebula instead of Tailscale, if I can figure it out.

Authelia is great. Recently added protection for multiple domains.

I just use google OAuth since everyone I know has a google account. It just can’t use OAuth on private IP addresses, just FQDNs.

I don’t think a tailscale tunnel helps this anyway, maybe just from standard antispoofing and geoblocks, but it still gets to the application in full eventually, when they can do what they’d do if it was directly exposed. The attack surface might be an entire API, not just your login screen. You have no idea what that first page implements that could be used to gain access. And they could request another page that has an entirely different surface.

If someone has Nextcloud exposed, I’m not stopping at the /login page that comes up by default and hitting it with a rainbow table; I’m requesting remote.php where all the access goodies are. That has a huge surface that bypasses the login screen entirely, might not be rate limited, and maybe there’s something in webdav that’s vulnerable enough that I don’t need a correct token, I just need to confuse remote.php into letting me try to pop it.

You can improve this by putting a basic auth challenge at least in front of the applications webpage. That would drastically reduce the potential endpoints.

It’s not required, but probably OP has a home server with Immich and a VPS which exposes it to the internet. In that setup you need Tailscale for the VPS to access your home server. Sometimes you can’t directly expose your home server for different reasons, e.g. ISP doesn’t give you an external IP directly (I’ve had this, where my router would get a 10.x IP so I couldn’t port forward because the internet IP was being shared between multiple houses), or the ISP gives you a dynamic IP so there’s no guarantee that your IP won’t change next time you reset the router, etc.

Also it provides an extra layer of separation, so for example a DDOS would hit the VPS which probably has automatic countermeasures, and even if someone were to gain access to the VPS they still need an extra jump to get to the home server (obviously if they exploit something on immich they would get direct access to the home server).

deleted by creator

I think self hosting the proxy with the services at hobbyist scale mitigates most of the security risks. The single point of failure risk is another matter. I once had to effectively reverse-hack my services by uploading a Jenkins test job through an existing java project to regain access. Ever since then, I maintain a separate ddns address that’s just used for emergency ssh access.