Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
From their blog post (linked to by the docs page) about self-hosting:
The following Omnivore features will not be included inthis minimal Omnivore setup:
- The web app (we will use the iOS app from the AppStore as our client)
- Search of PDFs
- Saving URLs instead of pages (more onthis below)
-Receiving newsletters via email
- Text to speech
Not only that, they use a non-self hosted elasticsearch provider.
Their example docker-compose file in the repo has no less than four containers defined, not including the database server, and you have to build them all yourself, so it’s more of a local dev environment type deployment rather than production.
All of that was more than enough for me to not even bother to try to deploy my own instance. I manage with Wallabag for now, it’s not the greatest implementation either but at least it can be self-hosted. Omnivore looks slick but the backend just doesn’t keep up.
Thanks for this. I think this is also an example of a opensource software that is selfhostable, but is intended for a different audience. I think Zammad, Monicahq etc fall under this category. I suppose one would need a solution with an entirely different architecture that’s aimed for selfhosters, rather than hope that omnivore becomes easier to selfhost.
As far as I can tell this just fixes some relatively minor issues the contributor was experiencing deploying the hacky self-host stack on his Kubernetes home lab or private server. It doesn’t bring anything new to the table, and I’m not sure that a full on Kubernetes or similar distributed swarm deployment is really what the average self-hoster needs or even wants.
It could just be that Omnivore tries to do too much for it to be feasible to self host. It was also conceptualized with certain third-party backend services in mind which makes it tricky to adapt.
Maybe I’m asking for too much, but I would be looking for a two service stack, one for the app and one database service. The current and forseeable future state of Omnivore is four backend services excluding the database, and like I already pointed out you’re not even getting the full feature set.
Can you elaborate on your experiences so far? What’s required in order to selfhost it, and what features will be missing…?
From their blog post (linked to by the docs page) about self-hosting:
The following Omnivore features will not be included in this minimal Omnivore setup: - The web app (we will use the iOS app from the AppStore as our client) - Search of PDFs - Saving URLs instead of pages (more on this below) -Receiving newsletters via email - Text to speechNot only that, they use a non-self hosted elasticsearch provider.
Their example docker-compose file in the repo has no less than four containers defined, not including the database server, and you have to build them all yourself, so it’s more of a local dev environment type deployment rather than production.
Here’s their “make self-hosting more practical” Github issue, coming on two years old with no progress: https://github.com/omnivore-app/omnivore/issues/25
All of that was more than enough for me to not even bother to try to deploy my own instance. I manage with Wallabag for now, it’s not the greatest implementation either but at least it can be self-hosted. Omnivore looks slick but the backend just doesn’t keep up.
Thanks for this. I think this is also an example of a opensource software that is selfhostable, but is intended for a different audience. I think Zammad, Monicahq etc fall under this category. I suppose one would need a solution with an entirely different architecture that’s aimed for selfhosters, rather than hope that omnivore becomes easier to selfhost.
https://github.com/omnivore-app/omnivore/pull/2966
Here seems to be a recent PR of someone trying to help out with this, maybe you can give a hand? Seems you understand a bit about the topic.
As far as I can tell this just fixes some relatively minor issues the contributor was experiencing deploying the hacky self-host stack on his Kubernetes home lab or private server. It doesn’t bring anything new to the table, and I’m not sure that a full on Kubernetes or similar distributed swarm deployment is really what the average self-hoster needs or even wants.
It could just be that Omnivore tries to do too much for it to be feasible to self host. It was also conceptualized with certain third-party backend services in mind which makes it tricky to adapt.
Maybe I’m asking for too much, but I would be looking for a two service stack, one for the app and one database service. The current and forseeable future state of Omnivore is four backend services excluding the database, and like I already pointed out you’re not even getting the full feature set.