Until it gets a security audit, I’ll stick with Signal.

I use KDE Connect for laptop to desktop transfers.

Tried it a couple times. Went back to the CLI.

If you know the CLI or are willing to learn, the GUI is yet-another layer for bugs to exist.

I think there is a catch-22.

pg_dump needs to connect to a running PostgreSQL instance.

But if you upgrade the binaries and try to start up, you can’t because the old data format doesn’t work. Because you can’t start up, pg_dump can’t connect.

I’ve spend more than a decade supporting both Postgres and MongoDB in production.

While they each have quirks, I prefer the quirks of Postgres.

I just spent a massive amount of time retooling code to deal with a MongoDB upgrade. The code upgrade is so complex because that’s where the schema is defined. No wonder MongoDB upgrades are easier— the database has externalized a lot of complexity that now becomes some coders problem to deal with.

For minor version upgrades, the database remains binary compatible. Nothing to do.

The dump/restore required during major upgrades allows format changes which enable new features and performance improvements without dragging around cruft forever to stay backwards compatible.

For professionals running PostgreSQL clusters in production there is a way to cycle in the new server version with zero user-visible downtime.

Discussions about hosting on your hardware is more likely to be discussed as “homelab”.

It doesn’t improve security much to host your reverse proxy outside your network, but it does hide your home IP if you care.

If your app can exploited over the web and through a proxy it doesn’t matter if that proxy is on the same machine or over the network.

I would recommend automating only daily security updates, not all updates.

Ubuntu and Debian have “unattended-upgrades” for this. RPM-based distros have an equivalent.

What do you check two hours later?

It’s so old it’s not called self-hosted.

Moneydance https://moneydance.com/

Started using it close to twenty years ago and keep using it because it seems fine.

Immich has a whole set of end-to-end automated tests to ensure they don’t accidentally make public any URLs they went to be private:

https://github.com/immich-app/immich/tree/main/e2e/src/api/specs

As a popular open source project, that would be e glaring security hole.

Using this proxy puts the trust in a far less popular project with fewer eyeballs on it, and introduces new risks that the author’s Github account is hacked or there’s vulnerability in he supply chain of this docker container.

It’s also not true that you “never need to touch it again” . It’s based on Node whose security update expire every two years. New image should be built at least every two years to keep to update with the latest Node security updates, which have often been in their HTTP/HTTPS protocol implementations, so they affect a range of Node apps directly exposed to the internet.

A simpler way to protect a private service with a reverse proxy is to only forward HTTP GET requests and only for specific paths.

It’s extremely difficult to attack a service with only GET requests.

The security of which URLS are accessible without authentication would be up to immich.