(This is a repost of this reddit post https://www.reddit.com/r/selfhosted/comments/1fbv41n/what_are_the_things_that_makes_a_selfhostable/, I wanna ask this here just in case folks in this community also have some thoughts about it)
What are the things that makes a selfhostable app/project project good? Maybe another way to phrase this question is, what are the things that makes a project easier to self-host?
I have been developing an application that focuses on being easy to selfhost. I have been looking around for existing and already good project such as paperless-ngx, Immich, etc.
From what I gather the most important thing are:
- Good docs, this is probably the most important. The developer must document how to self-host
- Less runtime dependency–I’m not sure about this one, but the less it depends on other services the better
- Optional OIDC–I’m even less sure about this one, and I’m also not sure about implementing this feature on my own app as it’s difficult to develop. It seems that after reading this subreddit/community, I concluded that lots of people here prefer to separate identity/user pool and app service. This means running a separate service for authentication and authorization.
What do you think? Another question is, are there any more good project that can be used as a good example of selfhostable app?
Thank you
Some redditors responded on the post:
- easy to install, try, and configure with sane defaults
- availabiity of image on dockerhub
- screenshots
- good GUI
I also came across this comment from Hacker News lately, and I think about it a lot
https://news.ycombinator.com/item?id=40523806
This is what self-hosted software should be. An app, self-contained, (essentially) a single file with minimal dependencies.
Not something so complex that it requires docker. Not something that requires you to install a separate database. Not something that depends on redis and other external services.
I’ve turned down many self-hosted options due to the complexity of the setup and maintenance.
Do you agree with this?
To me, the point of Docker is having one container for one specific application. And I see the database as part of the application. As well as all other things needed to run that application.
Since we’re here, lets take Lemmy for example. It wants 6 different containers with a total of 7 different volumes (and I need to manually download and edit multiple files before even touching anything Docker-related).
In the end I have lemmy, lemmy-ui, pictrs, postgres, postfix-relay, and an additional reverse proxy for one single application (Lemmy). I do not want or need or use any of the containers for anything else except Lemmy.
There are a lot of other applications that want me to install a database container, a reverse proxy, and the actual application container, where I will never ever need, or want, or use any of the additional containers for anything else except this one application.
So in the end I have a dozen of containers and the same amount of volumes just to run 2-3 applications, causing a metric shit-ton of maintenance effort and update time.
I agree with this. If you are going to be using multiple containers for a single app anyways, what is the point of it being in multiple containers? Stick all of it in one container and save everyone the hassle.
It’s because of updates and who owns the support.
The postgres project makes the postgres container, the pict-rs project makes the pict-rs container, and so on.
When you make a monolithic container you’re now responsible for keeping your shit and everyone else’s updated, patched, and secured.
I don’t blame any dev for not wanting to own all that mess, and thus, you end up with seperate containers for each service.
I can see why editing config files is annoying, but why exactly are two services and volumes in a docker-compose file any more difficult to manage than one?
See it in a broader scope. If I’d only host Lemmy with is multiple mandatory things, I couldn’t care less, but I already have some other applications that I run via Docker. Fortunately I was able to keep the footprint small, no multiple containers or volumes for one application, but as said: those exist. And they would clutter the setup and make it harder to maintain an manage.
I also stand by my point that it is counter-intuitive to have multiple containers and volumes for just one single application.
Ok but is there room for the idea that your intuitions are incorrect? Plenty of things in the world are counter-intuitive. ‘docker-compose up -d’ works the same whether it’s one container or fifty.
Computer resources are measured in bits and clock cycles, not the number of containers and volumes. It’s entirely possible (even likely) that an all-in-one container will be more resource-heavy than the same services split across multiple containers. Logging from an all-in-one will be a jumbled mess, troubleshooting issues or making changes will be annoying, it’s worse in every way except the length of output from ‘docker ps’
docker psor Portainer as a nice web-UI wrapper around the Docker commands are the two main use cases with Docker I have have on a regular basis.No, thank you. I am not going to maintain fifty containers and fifty + X volumes for just a handful of applications and will alway prefer self-contained applications over applications that spread over multiple containers for no real reason.
but there is a reason i just explained it to you
I think the reason is stupid and it is contrary to what I expect from dockerized applications.