yes, a bind mount / bind volume is when a volume is explicitly mapped to a location in your local storage rather than managed by docker and likely owned by root.

https://docs.docker.com/compose/compose-file/compose-file-v3/#volumes

Bind mounts. Always use bind mounts for data you care about, otherwise the “managed by docker” volumes are fated to be forgotten.

It won’t be your file structure as the file tree is managed by paperless, but at least using bind mounts you can easily navigate files and back them up independently or docker and paperless.

you don’t even need to think about letsencrypt

Do you know if it’s just as friction-less to have a self signed cert up with Caddy for internal use? I was using Nginx PM recently and had the need to serve https but I can’t use letsencrypt because it’s not public-facing. Nginx PM only has letsencrypt as an option.

I wish there was a checkbox that just deployed a self-signed cert without bothering with the details (it’s 2024 ffs, HTTPS should be 1 click away, whether that’s self-signed or not).

huh? What happened? Who’s shitting on ARM?

At ~5GB per HOUR? I don’t think so

Bandwidth (disk and network) is just one metric. Could it be an increase in number of IOPS due to syncing several small files?

Nothing, go ahead.

if these are the only services one is self hosting, I can see that.

But I have around a dozen stacks atm and I never came across a situation that I wanted to trigger an *arr stack restart with Jellyfin’s. They’re pretty much unrelated and independent services from an operational view.

I solved this last week by using Easy Effects and enabling AutoGain as an output effect.

Same experience here. Jelly’s volume is always 100% and I still often need to increase the TV’s or OS level.

yes, but I use one alias for all stacks to down, pull, up as a daemon, and watch its logs.

So I’d rather split the stack than have a special treatment for it.

I created them in the same compose but will probably split them up soon. There’s no point in having them in the same file: *arr services and jacket interact with each other, but Jellyfin is its own thing and I often want/need to restart it alone. They’re best as 2 separate stacks imo.

I knew they provided some “perks” to incentivize using their own router, like free support and compatibility with other junk they push to customers, but actively forcing users should be forbidden.

Do you also have to pay to “rent” the device?

I ditched portainer earlier this year to use the command line only, and don’t miss it at all. If you’re only using docker compose, I really don’t see the point of it.

deleted by creator

fwiw I’ve been using cloudflare tunnels with mullvad for almost a year and never had problems accessing my stuff.

I recently ditched Portainer entirely - it looks good, but when debugging anything it is really not helpful and often gets in the way. And if it runs on the first try I don’t need a web interface.

My tips:

• Run self hosted things on Linux and open their webpages on Windows if you really want or need to keep using Win.
• Prefer docker compose “stacks” over docker directly or native installs. Personally, I just use 4 sub-commands for pretty much everything I do: up, down, pull and logs. You (probably) don’t need Portainer.
• If after 1. making sure the docker-compose.yaml is right, 2. setting up the .env file if present, and 3. following the instructions in their README; a container stack doesn’t run after 2 or 3 attempts: copy the error message and search their GitHub issues - chances are someone else also faced that problem. If you can’t find anything similar, open a new issue.

I didn’t even know there was a Clarkson. This is beautiful.

it depends, they break even if you run them for many hours a day, but for smaller / quicker workloads they can make a lot of sense

I had Portainer setup, but it was clunky and the web UI added little value.

Now I just have a local git repo with a directory for each compose stack and run docker compose commands as needed. The repo holds all yaml and config files I care to keep track. Env variables are in gitignored .env files with similar .env.example in version control. I keep sensitive info in my password manager if I have to recreate a .env from its example counterpart.

To handle volumes, I avoid docker-managed volumes at all costs to favor cleaner bind mounts instead. This way the data for each stack is always along with the corresponding configuration files. If I care about keeping the data, it’s either version controlled (when mostly text) or backed up with kopia (when mostly binary).