I’ve always seen these self hosted S3 API compatible services as something a developer would use for testing.

Could maybe simplify the solution with https://syncthing.net/ or https://restic.net/ for self hosted backups.

Paperless will store documents in plain text. Maybe one could write a small webserver or extend Paperless to serve an RSS feed that could be consumed by Yacy.

For a couple reasons

1. Store and version configs in git. I realize unRAID provides flash drive backup (using git also), but this allows me to spin up my setup on another machine that may not be running unRAID. Helped recently when I switched away from Proxmox.

2. Allows me to group services with their dependencies. ( e.g. postgres, redis, etc ) Also can help isolate service groups from each other. Avoiding port conflicts on common db ports for example. Downside being may have more than one database, redis, etc.

Note, there is an unRAID docker compose plugin so you can still get easy access management buttons to start, stop, view logs, and edit services.

I have a very similar setup minus the iot and metric related services. I’m managing the services with Docker Compose on unRAID.

Good point, if supporting JS disabled browsing is a goal, SSR is a must.

re languages If doing SSR, language matters. If doing CSR, statically generating site, it matters less. For example, there are more hosting options for PHP than Rust. There are even more hosting options for static assets (eg CDN).

The power of Social Media is the community. Coupling the UI with Rust seems like it would prevent the larger community from contributing. I’m interested in both web and Rust, but have zero interest learning a Rust JSX variant.

Why not static site? Could have a themes folder where admins could drop their static themes. Also, would allow admins to host markup and Lemmy API on different hosts.

Your data/content is public on Lemmy, FB would have no problem fetching it.

Your edit is correct. SSO not required.

Probably want to keep services with different life cycles in separate docker compose files to allow you to shutdown/restart/reconfigure then separately. If containers depend on each other, then combining into compose file makes sense.

That said, experimenting is part of the fun, nothing wrong with testing it out and seeing if you like it.