Sure, the docs are pretty minimal though: https://wiki.servarr.com/prowlarr/settings (just click on Proxy)

Basically you can configure a proxy (from your VPN provider for example) for each indexer (or font add a tag to apply it to all of them), and queries to indexers will run through there. This avoids Sonarr making calls to TVDB or whatever through the VPN and getting blocked.

Trash guides say you shouldn’t run the *arr’s through a VPN because you’re likely to get blocked by metadata servers. I only run my download client through the VPN + also use gluetun’s HTTP proxy for Prowlarr’s indexers

Use gluetun, look up how to configure for your provider. Run a 2nd container for your torrent client, using network_mode: “service:gluetun” to run all your traffic though the vpn. Note that if you’re forwarding ports from your client to e.g. access the web UI, you’ll need to forward them from the gluetun container instead.

You still have to have indexers, so you need to deal with them indirectly, but the UI is sooo much nicer. Sonarr/Radarr are pretty easy too. If you know your way around docker you can get it up and running pretty quick.

Awesome, thanks!

An the issue is only inside the network? I’d complain to IT about that, yeah. Maybe they are overriding the DNS record with their own DNS server or something.

Can you set your own DNS servers on your client devices? Does cloudflare or quad9 resolve it?

Do you have a static IP? If not, have you tried some kind of dynamic DNS like DuckDNS?

This is true. However many big maintained public images are multi-arch so down for ARM, and the fact that Docker runs in a VM on Windows and OSX when you install it doesn’t matter to most people. On Linux indeed it reuses the host’s kernel (which is why containers can be a lot lighter than VMs)

It’s not NAS specific, it’s platform independent - that’s the whole point. You have an application you want to run, and you package it all up into a docker image which contains not only the application but it’s dependencies and their dependencies all the way down to the OS. That way you don’t need to worry about installing things (because the container already has the application installed), all you have to do is allocate some resources to the container and it’s guaranteed* to work

*nothing is ever as simple as it first appears

One area where this is really helpful is in horizontally scaling workloads like web servers. If you get a bunch more traffic, you just spin up a bunch more containers from your server image on whatever hardware you have laying around, and route some of the traffic to the new servers. All the servers are guaranteed to be the same so it doesn’t matter which one serves the request. This is the thing kubernetes is very good at.

Edit: see caveats below

This is definitely a job for templating, seems you’ve got the right tool to me!

So far I just hand roll my docker-compose (at home, anyway). However, docker-compose does also support overrides via yaml merging, maybe that’s worth looking into?

My idea with that is to have a base compose that configures also my services and then to have a few override yamls with environment specific stuff (like prod, local, …)

This is similar to Kustomize from kubernetes land which I’ve worked with in the past

I also wanted too know so I looked it up:

Usenet “Block Accounts” are accounts where Usenet access is purchased by the gigabyte (GB). For example, a 100 GB block account will allow you to download up to 100 GB of data from a Usenet feed. Most block accounts have no expiration date so you can use them for years. Many people use block accounts as backup accounts to fill in files missing from their main Usenet feed.

I came here to comment this. It feels really esoteric but great selection!