This is for a previous build but should be a decent starting point.
#16 (comment)

I am still trying to tink about a good docker-compose setup. For now you can just execute the docker container with the subcommands as you wish, as described in the readme.

Docker-compose is used to let containers run via a yaml configuration file to make it simple. But this container is not designed to always run, it is only used to run once, execute the command and then quit.

The idea that I have right now is providing a docker-compose setup where you can run excludarr in a cronjob, so it runs periodically. What do you think about that idea?

I'm no expert, but assuming it's using virtually no resources while not checking, I think I'd want a container that's up all the time, but one of the environment parameters set tells it how frequently it fires up.

Great, exactly my idea. I will update the docker container in version v1.1.0. Planning to release it in january.

To chime it I would think it would be best to run like unpackerr as @stgreenb said since it takes up virtually no resources when not in use and I imagine not much when in use.

I checked here since I am having the same issue, but there is also no log output so I do not know what to fix.

currently it is not ready for docker-compose as it is a CLI based application that run once and then stops. I am also a big fan of docker and docker-compose, but I guess first it needs to have some UI around it before it can run like a 'service' using docker-compose.
So right now it is docker run -- etc. :)

To chime it I would think it would be best to run like unpackerr as @stgreenb said since it takes up virtually no resources when not in use and I imagine not much when in use.

I checked here since I am having the same issue, but there is also no log output so I do not know what to fix.

This was exactly what I was thinking. Unpackerr runs without needing interaction and just starts every day at a set time by environment variable.

This would also be good for those of us who use Kubernetes as the docker CLI isn't really an option for us. If the container can just run without interaction then it can keep working away regularly.

If the delete option isn't selected, it could maybe send the results out to a log file each time it runs rather than printing to screen? This is what unpackerr does so you can view the log outside the container.

This has been added in version 1.0.6. See the README.md docker-compose section for information on how to set this up. You will need to create a crontab file and mount it into the container. You should also set the CRON_MODE setting to true in order to let it run using cron.

The existing functionality is still the same, so you can still run the command once using docker as before without any changes. Let me know what you think about it!

Rather than mounting an external cron would it not be more elegant to have the cron included in the image and adjustable via environment variable?

Yes it would be more elegant and I have thought about it for a while and figured that this solution was the easiest giving the users full control.

I have thought about a solution to configure it via environment variables. But the thing is that excludarr supports multiple sets of commands and options. Those options defines what the user wants and needs. Making that configurable via environment variables would be really hard to maintain, especially when features are being added to excludarr.

The mounted cron file gives a user full control over what should be running and when. However I am open to other kinds of solutions, if they are maintainable and usable.