I just made a mirror out of two NVMes―they got cheap enough not to bother too much with the loss of capacity. Of course, that limits what I can put there, so I use a bit of a tiered storage between my NVMe and HDD pools.

Just think in terms of data loss: are you going to be ok if you lost the data between backups? If the answer is yes, one NVMe is enough.

Another alternative: https://pushover.net/

You don’t need -it because you don’t run an interactive session in docker. It might be failing because you ask for a pseudoterminal in an environment where it doesn’t make sense.

Seq is expecting structured logs which yours aren’t. So you want to either convert your app’s logs into a structured format (which is generally hard for a random third-party application) or use a log collector that’s fine with non-structured logs (e.g. Loki+grafana don’t care about the shape is your logs and you can format the output while querying).

I’ve been using FreshRSS and Reeder (now Reeder Classic) since google reader stopped being a thing. It’s pretty great.

This looks nice, but there’s plenty free alternatives in this space which warrants a section in the readme with the comparison to other products.

You mention ram usage, but it’s oftentimes a product of event size. Based on your numbers, your average event size is about 800 bytes. Let’s call it 1kb. That’s one million events per day. It’s surely sounds more promising than Elastic, but not reaching Loki numbers, or, if you focus on efficiency, is way behind Victoriametrics Logs (based on peeking at their benches).

I think the important bits you need to add is how you store the logs (i.e. which indices you build) and what are your trade-offs. Grep is an efficient logs processor which barely uses any ram but incurs dramatic I/O costs, after all.

Enterprises will be looking at different numbers and they have lots of SaaS products to choose from. Homelab users are absolutely your target audience and you can have it by making a better UI than the alternative (victoriametrics logs aren’t that comfortable to work with) or making resource usage lower (people run k8s clusters on RPis, they sure wonder about every megabyte of ram lost) or making the deployment easier (fire and forget, and when you come to it, it works).

It sounds like lots of things and I don’t want to be discouraging. What you started there is really nice-looking. Good job!

I would not recommend unifi for a mature solution. It sure works nice as a glass panel, but it will get limiting if you will have a desire to hack around your network. Their APs are solid, though, it’s just the USG/Dream machine that I wouldn’t recommend.

Mikrotik software is very capable and hackable and you can run it in a vm if you feel like bringing your own hardware.

I went looking into how that works, and, apparently, tailscale adds individual node routes (in table 52). So yeah, you have very low chances of getting into trouble even if you have an interface with 100.64/10.

Yeah, you’re absolutely correct. I misread that thinking OP would have the CG NAT endpoint and taikscsle on the same physical device, which, I still think, would be a problem: you’d have two interfaces for 100.64.0.0/10. But if CG NAT terminates on the modem and you run taikscale on devices connected to it them there’s surely no issue at all.

I’m actually not sure you can easily get tailscale up and running om such as a setup as it uses the same cgnat ip range.