Since https://blog.cloudflare.com/updated-tos it is not completely clear if you disable Cloudflare's cache indeed. Still the terms are unclear enough that they could cut you out, and I'd feel uneasy exposing a Jellyfin instance publicly, but that's just me :)
This is very cool, but you should not use Cloudflare Tunnels to stream media. This is forbidden by their terms of service (or at the very least not the intended use of Tunnels and they may disable your service). Use Wireguard or Tailscale instead.
That's true. This specific attack was mitigated by hash pinning, but some actions like https://github.com/1Password/load-secrets-action default to using the latest version of an underlying dependency.
But then, your firewall or Cosmos is exposed to the internet waiting for a 0day to be released, and chances here they will not be updated as soon as it comes out.
VPN server is already what Tailscale does at this point. I'm not a shill by the way, just a regular user impressed by the ease of installation/use of their product.
I love my work-provided M1 MBP Max and would possibly consider getting a personal Air at this price range, but the 8gb RAM is still a no go for me, even for $699. My SO has a 2015 MBP that's still solid, and I credit that to its SSD and 16gb RAM. I can't see 8gb of RAM being usable in 2034.
This what we are doing for the prod container that does not have Composer installed yes.
But in development it's much easier to have it in the image. Additionally we do not bundle the code in the dev image but bind mount it in Docker Compose, which is much faster than rebuilding the image to test changes in development; PHP not being compiled allows us to do that to reduce the feedback loop duration.
PHP dev here, we have extensions for development that make no sense in production, xdebug for example. You need it for breakpoints and debugging in general but it should not be installed in production. So we extend our production image and install it on top of it. Similarly, we include Composer (package manager) in the dev image only as we only need the installed dependencies in production but not the package manager. Our dev image is a flavor of the production one, really.
Backend complexity as mentioned above, as well as potential performance issues. You really want to avoid N+1 issues by batching all the fields and relationships you want to query at once. It's too easy to realize you're running n queries for each field of every entity you are retrieving...