Why would you want to use this over one of the official docker compose setups? https://github.com/paperless-ngx/paperless-ngx/blob/main/doc...

They will also automatically launch if you have docker running at boot. Is it just because you prefer redhat/IBM's docker equivalent stack to the much more common and cross platform docker install?

I would want this over docker and docker-compose any day.

I've been using docker compose in production for a couple of years now and it adds another layer on top of systemd that is a continuous source of headache, especially during updates.

Podman gets it right: no central daemon, can automatically generate systemd services for a whole pod. Updates are seamless.

This by itself is enough of a reason to me.

Seconded on the things Podman gets right. Also the isolation of all of the containers in their own network name space makes port management on my workstation super easy. I run many things like Paperless NGX using the same pattern in the start.sh file of my little project. I then use Traefik to route traffic to the right pod. It works great.

I don't use Docker at all on any of my infra or workstations. That's why I made this.

Alright, but you've sort of re-invented docker compose there, but as a shell script. These days docker compose even work with podman if you really prefer IBM's docker implementation to the original.

I am well aware that docker compose works mostly with Podman. I prefer to use Podamn with systemd over it. I have you even tried giving this a shot? Maybe give using Podman + systemd following my example in Bash instead of Docker + Docker Compose and you will see why?

Well... Maybe re-inventing was part of the fun or a learning experience. If you want, there is even this: https://github.com/Mitigram/docker-compose-build

> everything you need to run Paperless-NGX (PostgreSQL, Redis, Tika, Gotenberg, PaperlessNGX, and SFTPGo)

That is a lot of dependency. How stable is Paperless with all those applications making uncoordinated changes on their own schedules?

The only hard dependencies are Redis and Postgres. The official stance is to run them from the provided docket compose and the container for paperless-ngx itself is kept updated and working for the stable containers of redis and postgres.

Tika and Gotenburg are additional features for scanning and converting MS Office documents to PDF. Not necessary and I don't use them in my setup at all. Same with sftpgo. I'm not sure for its usecase. But paperless doesn't directly depend on it in anyway.

Postgres didn't actually a requirement either. Sqlite is supported and default unless you provide configuration for connecting to a database host.

I've used the one click TrueNAS app for a while and it's been solid. I had less luck with the TrueCharts o variant.

Entirely possible the instability was my fault but the error messages didn't make it obvious what was wrong.

It's in this script so I can SFTP PDFs from my scanner over the network. Push button, scan paper and then it is SFTP'ed to a shared volume between SFTPGo and Paperless so it is detected and ingested into Paperless NGX automatically.

Even if you use :latest it doesn't update by itself.

Why does this need so many services? Is it meant to scale to enough users where you'd want postgres and Redis? Seems like everything but the machine learning on this could be pure Python if they wanted.

I'd probably still use it since there's awesome tools like this to set it all up, but it seems like a confusing architecture.