I don’t have a testing environment, but essentially all my services are on docker saving their data in a directory mounted on the local filesystem. The dockerfile reads the sha version of the image from an env file. I have a shell script which:

1. Triggers a new btrfs snapshot of the volume containing everyithing
2. Pulls the new docker images and stores their hashes in the env file
3. Restarts all the containers.

if a new Docker version is broken rolling back is as simple as copying the old version in the env file and recreating the container. If data gets corrupted I can just copy the last working status from an old snaphot.

The whole os is on a btrfs volume which is snapshotted regularly, so ideally if an update fucks it up beyond recovery I can always boot from a rescue image and restore an old snapshot. But I honestly feel this is extra precaution: in years that I run debian on all my computers, it never reached the point of being not bootable.

My Synology has an auto block feature that from my understanding is essentially fail2ban, what I don’t know is if such a feature works for all my exposed services but Synology’s

I’d be surprised if it works for custom services. Fail2ban has to know what’s running and haw to have access to its log file to know what is a failed authentication request. The best you can do without log access is to rate limit new tcp connections. But still you should know what’s the service behind because 5 new SSH sessions per minute and IP can be reasonable 5 new http1.0 connections likely cannot load a single html page.

If you want to encrypt only the data partition you can use an approach like https://michael.stapelberg.ch/posts/2023-10-25-my-all-flash-zfs-network-storage-build/#encrypted-zfs to ulock it at boot.

TL;DR: store half of the decryption key on the computer and another half online and write a script that at boot fetches the second half and decrypt the drive. There is a timewindow where a thief could decrypt your data before you remove the key if they connect your computer to the network, but depending on your thread model can be acceptable. you can also decrypt the root portion with a similar approach but you need to store the script in the initramfs and it is not trivial.

Another option I’ve seen suggested is storing the decryption key on a USB pendrive and connect it with a long extension cord to the server. The assumption is that a thief would unplug all the cables before stealing your server.

A more detailed guide for dropbear: https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/

If I remember correctly, the only outdated bit of information is that the IP configuration doesn’t happen anymore in the initramfs configuration but you must pass a parameter at the kernel by editing /etc/default/grub and passing

GRUB_CMDLINE_LINUX_DEFAULT="ip=192.168.x.x:::::"

where 192.168.x.x is the IP address that you want at boot

I’ve been using CommaFeed for a while and I’m very happy with it. https://github.com/Athou/commafeed/ plus it is actively developed. I’ve reported a couple of small feature requests and the author implemented them very quickly.

As far as I know there are many third party android apps that you can use, but its responsive webUI is good enough, once you install it it is essentially as good as an app.

As other mentioned, an advantage is that it blocks ads on phone apps too. My other use case is to add extra DNS entries to name devices on my local network. Finally, after using pihole for a while I switched to blocky. It has similar features but it lacks the UI and the dchp server, but in exchange it uses much less resources. Since I didn’t use either of these it sounded a good trade to me

Devices are named after characters from books I recently read, trying to match the name with the character of the book. But for virtual hosts for services I use their purpose (wiki, files, feed…) because I wasted too much time updating all the bookmarks last time I migrated to a new server.

I started using headscale (the opensource reimplementation of tailscale server) on a private vps. It is incredibly better compared to plain wireguard. I regret waiting so much before switching.

Something that really made my life easier: wireguard is poor at roaming: switching to and from my wifi created issues because the server wasn’t reachable anymore from its public ip and wireguard didn’t bother to query the DNS again to check the new IP. Also, configuration is dead simple because it takes care of iptables for you (especially good when you enables forwarding to a node).

Since the server just sends small messages for the control plane and all the traffic is p2p between the devices, the smallest vps with the smaller connectivity is more than enough to handle it.

If security is one of your concerns, search for “HTTP client side certificates”. TL;DR: you can create certificates to authenticate the client and configure the server to allow connections only from trusted devices. It adds extra security because attackers cannot leverage known vulnerabilities on the services you host since they are blocked at http level.

It is a little difficult to find good and updated documentation but I managed to make it work with nginx. The downside is that Firefox mobile doesn’t support them, but Firefox PC and Chrome have no issues.

Of course you want also a server side certificate, the easiest way is to get it from Let’s Encrypt