I was devastated when Google Reader shut down. I switched to another service after that and it shut down not long after that. Maybe a year or so.
I would have paid for that service at the time.
I was devastated when Google Reader shut down. I switched to another service after that and it shut down not long after that. Maybe a year or so.
I would have paid for that service at the time.


Regarding certificates. I use Caddy for things like that. Even stuff that I don’t want publicly available. It is technically public, but relatively secure.
I use a combination of basic authentication plus a rate limit so the password cannot be brute forced. And then I have a bypass so that auth is not required on my home network. I think it works pretty well.
Of all the things on this, the one I’m most confused about is the Serious Sam logo.


I can confirm the dev is great. I had two feature requests and they did a great job communicating and then implementing those requests.


I’m thinking about finding an alternative to ntfy. The maintainers are increasingly vibe coding it.


There’s also an image for Copyparty if you’re already hosting stuff as containers. It’s super handy.


I would use Debian for servers, except that the version of Podman (at least on Debian 12) was old enough that it couldn’t do quadlets. So I went with Fedora.


I run Rancher Desktop on Windows… But only because my company won’t let me use Linux, and I only use it for Dev and testing.
All that to say, I have no idea why else you would be running a container engine on a Windows host.


+1 for Ubiquiti, but I’d suggest one of the cheaper models with built in WiFi unless you plan on having an intricate network.


I course the middle option for things I’m not hosting, but could see myself hosting in the future.


The worst part about quadlets, IMO, is that they don’t use the same key words as podman run does. So turning a working podman container into a quadlet can be challenging.


Check out Tailscale. It uses Wireguard under the hood, but it’s magic.
containers should be immutable and not be able to write to their internal filesystem
This doesn’t jive with my understanding. Containers cannot write to the image. The image is immutable. However, a running container can write to its filesystem, but those changes are ephemeral, and will disappear if the container stops.
So, slightly tangential, but I have a failed home automation project this past week.
I have been using an unofficial integration for my mini-splits for a few years. The guy who wrote it likes to disappear for 6 months at a time and it seems like it may be abandoned. It finally stopped working after a home assistant update.
I had bought some ESP based replacement dongles about a year ago and decided to finally use them. Well, not all of the features worked, so I set about writing my own firmware.
That ended up working even less well. I wasted a lot of time and effort trying to get my firmware to work before giving up and just moving to the fork of the original Home Assistant integration for the official dongles.
I hate being beholden to third party stuff like this because I have robust automation setup for my mini-splits and updates can completely break them and be a massive pain to fix.
I’m not sad I tried and failed so much as I’m just sad it didn’t work. I may try again sometime in the future.


No reason you can’t use NixOS in a VM on Proxmox.
My container host OS is another immutable, uCore, which I run in a VM on Proxmox.


I did this recently. Opendrive is free up to 5 gb and works with rclone. All I’m backing up is the config and data needed to recreate my containerized services. I’ve even had to recreate them from the backup, once.


The N100 is such a little powerhouse and I’m sad they haven’t managed to produce anything better. All of the “upgrades” are either just not enough of an upgrade for the money, it just more power hungry.


That looks very similar to ntfy. I googled “gotify vs ntfy” and found this thread on reddit (ew, I know) https://www.reddit.com/r/selfhosted/comments/shw73e/difference_between_ntfy_and_gotify/
Con: User separation. A user can create “apps” (channels), and will receive messages posted there. Users will not receive messages posted to apps they didn’t create. I haven’t yet found a way to create shared apps, or allow multiple clients to receive notifications for a given message, and I don’t want to share client logins.
Now, this thread is 3 years old, so I don’t know if this is still the case, but this is a deal breaker for me. Several of the topic I have for ntfy are also subscribed by my wife, meaning we both get the notifications. I could just post the same message to two different topics, but that would be lame.


Ntfy, if setup correctly, uses a web socket connection, which reduces the battery usage. I don’t think I ever had it setup without that, so I can’t say how bad it is. But with it, it’s not a drain for me on a Pixel 7.

I just recently went through a much more benign, but scary nonetheless version of this.
I realized that my Ansible directory, that I had made public on GitHub to share as an example to some folks, had secrets committed and pushed.
It was the direct URL and credentials of an app I developed to store non-PII customer data. Now, it wouldn’t be the end of the world if someone noticed this and scraped the data, but it wouldn’t be good, either.
Luckily, I have Caddy access logs, and it appears no one ever accessed it.
So I pulled the secrets out of the Ansible directory and made the repo private, I rotated the credentials, and installed Crowdsec to monitor Caddy access logs and ban bad actors.
I only noticed the secrets because I had just setup Authelia as an OAuth2 provider for my homelab, and I was adding it to my backup scripts.