I run tt-tss on a shared web hosting to provide it to a small group of family members.
Update is done irregularly. Usually twice a year. That is very a convenient way to run tt-rss without the need of taking care of the whole system setup (speaking of web server, database server, etc.). Additional advantage is that web space on a shared hosting provider is usually cheaper than a VPS and more reliable than hosting it at home, e.g. on a RaspberryPi. You don’t need to drill holes in your router’s firewall, too, in the latter case.
That’s an amusing way of putting it. In the future I’m going to say, “Drill holes in your firewall,” instead of, “Opening a port.” 
@JustAMacUser, you’ve got me. Certainly, it is daily use case to open ports in a firewall to provide access to a service. By “drilling holes” I expressed it in a slightly more dramatic way to emphasis that one should consider the risk running services inside a home network, which are accessible from outside.
Azure Web App for Containers (Compose mode) + Azure DB for PostgreSQL. Mainly did it because I prefer a fully managed DB instance.
Sandstorm (on a home SBC).
Other: git install in a systemd-nspawn on a VPS. Before that (a few months ago), directly on a VPS.
free tier aws in docker
I run tt-rss using podman on a small machine running Fedora 34.
I’m running a somewhat eccentric setup of tt-rss on a Ubuntu Scaleway VM.
I’m building a Systemd Portable service image with NixOS, using uwsgi as the php application server. And then just run it as a portable service with the host nginx and mysql as a service .