Definitely run it in a container. It’s a great application, but it has several documented security holes. You’ll want it to be as restricted as possible, so if a major exploit does come about, it won’t do much harm.

I’ve been running rootless Podman (with the exception of my reverse proxy, because privileged ports) without any issues, though my one challenge has actually been documentation - specifically for podman-compose, which seems to be a complete void.

Using podman-compose, I usually have a section like:

volumes:
    - ./local_folder:/container/folder

Specifically, I have to use either an absolute path or a relative path with “./” to prevent it from treating a directory as a volume name.

My practical answer: Nah, it’s probably not going to nuke your files.

My software engineer answer: Never trust us to not make a mistake. It doesn’t take much to accidentally nuke a directory.

Agreed, for me containers are really nice for playing with new software without dirtying my host install.

I’m actually almost completely unfamiliar with Nginx, short of a few hours of tinkering. NginxProxyManager is a direct competitor to Caddy, with a graphical interface, SSL cert creation and auto-renew, etc. I’m not going to say to switch from Caddy, since there’s probably no major benefit, but it’s much nicer than trying to figure out Nginx reverse proxies by hand.

I think the problem is that normal consumers wouldn’t ever buy a tape drive, so the only options still being produced are enterprise grade. The tapes are still pretty cheap, but the drives are absurd.

I really want to use tape for backups, but holy expensive. Those tape drives are thousands of dollars.

I’m going to cast another vote for a reverse proxy, such as NginxProxyManager. It’s really easy to set everything up, and they’re usually very easy to run in Docker/Podman.

One thing to note: if you end up with a domain with mandatory HSTS, you’ll have to use DNS-based certificate generation rather than HTTP based, since unencrypted HTTP is blocked (chicken/egg problem to get HTTPS working). It’s not hard, but you have to be aware of that limitation.

I think it’s another fine example of Canonical pushing its own products rather than supporting and enhancing existing standards (flatpak and appimage), which people are getting tired of. Also, as I understand it, the snap store itself is proprietary and is therefore controlled by Canonical.