That’s low utilization. If your ram was fully used and stuff was being frequently stopped, that’s when I would be concerned (and when you would experience wear on your SSD).
Right now you have less than a quarter used, and a couple things the kernel decided to swap out. Perfectly normal.
You should simulate a number of repos and users to produce a realistic estimate. I would find that extremely useful, as would some of my colleagues at work. You should be able to scale up to a few hundred of each without too much trouble, and there will be no risk to running into any limits. I’m looking forward to this!
Fifty pounds??? Yeah that’s not going to work with just front rack ears, even if the batteries were all the way to the front.
If it’s all internal (and you haven’t set up any extra firewall zones or rules) then you won’t need any firewall rules to allow it.
You should probably be able to just ping immich.homelab.internal right now, and make an http request and get something back too. Even if it’s an http error, that still means you’re talking to an http server successfully.
I haven’t used opnsense in years, and I’ve never used caddy, so I don’t know if the config is right, but it looks reasonable and the concepts are the same as what I’m used to.
Measure the screw holes and check them against other ears. They might be a fairly common pattern.
Also make sure that the ears will properly support the weight of the UPS. Lead-acid batteries are hefty. I can’t tell from a quick search how it’s supposed to be set up. It might need ears front and back. Or, you might find full rails.
If all else fails, get a rack shelf and just let it sit on it. Or get some scrap wood and/or steel and fabricate something.
Can’t get any simpler than the terminal, can you? I just paste links into the terminal after a yt-dlp command.
You don’t need an external domain. Use .internal as your tld and you can use whatever domain your want. jellyfin.homelab.internal, for example.
I own a domain and run my internal stuff under internal records. Part of the reason for doing it this way is I can use the DNS challenge for issuing LE certs to the internal services automatically.
And no a reverse proxy will not expose anything to the Internet, unless you also open the port in your firewall (and forward it in NAT if it’s on the lan and you use NAT).
Check the Netbird relay setting and try toggling it. I recall some people mentioning it defaults to something that can cause slow connections.
It sounds to me like you just have a higher risk tolerance, and if you accept that, that’s okay.
You are welcome to expose it at your own risk. Assess you own tolerance for compromise (personal data compromise, becoming part of a botnet, becoming a host for spam or CSAM) and proceed accordingly.
Sure, any project designed to be exposed to the Internet. Web servers would be the most obvious.
That first page says exposing it to the Internet is “not recommended”. Putting a reverse proxy in front of it does not meaningfully change the security posture. A malicious request to http://jellyfin.homelab.com/exploitable-page will be sent to jellyfin in effectively the same way, whether through a reverse proxy or not. You would need a WAF set up specifically to look for relevant exploit attempts.
https://github.com/jellyfin/jellyfin/issues/5415
Those are some outstanding known vulnerabilities, most of them unfixed. They are not particularly severe, but it shows that thorough security is not a priority for the jellyfin devs.
There is no safe manner of exposing jellyfin.
Or run an internal CA, if you’re the only one accessing the services.
You will.
Anything you expose should be designed for it (e.g. not jellyfin). You should have a WAF configured for the type of service you’re hosting. You can’t just drop one and have it magically protect you, they take configuration. Same with fail2ban.
And you should have these services in a DMZ, so that a compromise in one doesn’t provide an entry point to other resources on your network.
There’s not nearly enough dog metrics on that dashboard
Please don’t expose jellyfin to the Internet. It is not hardened against attackers.
What’s your backup strategy?
I would open an issue asking for documentation.
It’s a good option if you can’t do anything better, like a VPN. Because there is always the risk of an authentication bypass vulnerability. The less attack surface, the better.