Interest in a website containing the docker-compose files of projects listed in the awesome-selfhosted list
from mrmn@lemmy.world to selfhosted@lemmy.world on 10 Feb 09:47
https://lemmy.world/post/25384920

Hi c/selfhosted,

I have another project idea. However, before I start I want to make sure there is interest in the community and a similar project does not exist yet.

I was thinking about a “compose” website that contains the compose files and basic information of the projects listed in the awesome-selfhosted list. Users can search for projects, browse by categories, etc. In my opinion when finding a new project you want to try out it, is a bit cumbersome to find the corresponding compose file to get started.

Let me know if there is any interest in such a project. Also I have no idea how I would name the project, so give me your best suggestions :). Thanks!

#selfhosted

threaded - newest

Strit@lemmy.linuxuserspace.show on 10 Feb 09:52 next collapse

While most have examples in their readme’s on Docker hub and Github, not all of them do, so I sometimes have to hunt down an example buried in their git repo somewhere. So a searchable page for popular self-hosted app docker compose files would be welcome.

I don’t think I’ve seen such a page anywhere else.

Tiritibambix@lemmy.ml on 10 Feb 10:03 next collapse

I know of these:

github.com/bitnami/containers/tree/main/bitnami/

github.com/docker/awesome-compose

They’re not specific to projects listed in the awesome-selfhosted list though.

Obelix@feddit.org on 10 Feb 10:07 next collapse

You might want to take a look at community-scripts.github.io/ProxmoxVE/ . That’s exactly what you want, but without Docker. It uses Proxmox / LXC / VMs and is really, really awesome for selfhosting.

SidewaysHighways@lemmy.world on 10 Feb 12:28 collapse

RIP ttek

Obelix@feddit.org on 10 Feb 12:40 collapse

I’m really happy that the community stepped up and continued his great work.

non_burglar@lemmy.world on 10 Feb 14:15 collapse

It’s not actually going that great, there is already infighting on the direction of the scripts.

SidewaysHighways@lemmy.world on 10 Feb 20:23 next collapse

that’s really disappointing!

Obelix@feddit.org on 11 Feb 18:04 collapse

Oh :( Do you have some more information about that? Which directions are being debated?

PunkiBas@lemmy.world on 10 Feb 11:39 next collapse

Have you looked at this?:

haxxnet.github.io/Compose-Examples/

[deleted] on 10 Feb 17:14 collapse

.

ikidd@lemmy.world on 10 Feb 18:07 collapse

Non-Fungible Tokens?

Jakeroxs@sh.itjust.works on 10 Feb 22:13 collapse

The website has one of those cringe nft monkeys, but otherwise the site looks good

Appoxo@lemmy.dbzer0.com on 10 Feb 12:13 next collapse

I’d assume the projects either have a docker-compose example in the readme or in the repository files alongside the actual project.
Is that so uncommon?

fine_sandy_bottom@discuss.tchncs.de on 10 Feb 13:35 collapse

It’s not that it’s uncommon, but slightly different for each project.

I collated library would be kinda cool.

That said, I don’t know how much utility this project would have.

Appoxo@lemmy.dbzer0.com on 10 Feb 13:37 next collapse

Yeah, that’s fair. Very convoluted and difficult documented.

AbidanYre@lemmy.world on 10 Feb 16:19 collapse

It might be cool, but it seems like it would be missing the context and documentation that would be present in it’s project repo.

fine_sandy_bottom@discuss.tchncs.de on 11 Feb 05:25 collapse

If only there were some way you could kind of refer viewers to the primary documentation for the project.

x00z@lemmy.world on 10 Feb 12:25 next collapse

Why compose and not just containers?

4am@lemm.ee on 10 Feb 14:25 collapse

Why would anyone use containers without compose?

Especially people who are newer? It’s far easier.

tripflag@lemmy.world on 10 Feb 15:31 next collapse

for a selfhosted service which is a single self-contained process in a single container, is there still a benefit to using compose, and if so, what would that be? genuine question since I’m not providing a compose example for a foss service I made.

catloaf@lemm.ee on 10 Feb 15:43 next collapse

I find it a lot easier to write out the yaml and save it in a file than to run a command every time, and I hate yaml.

lambalicious@lemmy.sdf.org on 10 Feb 16:36 collapse

Persistence of “mental state” mostly. By setting up a compose, you have a written down notion of things like volumes, environment variables and other elements stored somewhere for the behaviour of the container, that can not be ignored or defaulted if you don’t wish it, for when you need to undo and redo a container and default behaviours are important.

While sure, those elements can be set in a loooong ${engine} run… command, it’s easy to forget to set up something important or copy and paste an accidental endline. A compose file (plus a sample envfile, if you so wish) helps keep the way to set up variables and state under control. Made much easier now that we have both docker-compose run and podman-compose run.

x00z@lemmy.world on 10 Feb 15:32 next collapse

You answer my question with a question… But I’ll answer it.

Compose is meant for multi-container applications or development. It’s good for custom applications where you need to manage every service yourself so you mostly see them used for stuff like web stacks.

Single container applications are much easier to run and manage for the end-user and most of the awesome-selfhosted apps are already served as single container images on the docker hub. There is absolutely no need to use compose for any of those because you are not managing every service of the app yourself.

I have a big server with lots of containers running for apps. For example, I have a container for my blog, one for FreshRSS, and even one for Teamspeak. But I only use Compose for one application and that’s my own custom one. That one consists of an nginx container, php container, etc. I don’t need to dive into the different services of FreshRSS for example, but I do need to for my own custom app.

JollyGreen_sasquatch@sh.itjust.works on 10 Feb 18:30 collapse

Compose doesn’t have a versioned standard, it did for a bit iirc, which also means you can’t always just grab a compose file and know it will always just work.

Most self hosted works fine with giant all in one containers, even for complex apps, it’s when you need to scale you usually hit problems with an all in one container approach and have to change.

lambda@programming.dev on 11 Feb 00:37 collapse

Huh? They officially support it and there is no need for a version any more. It’s standardised. As a matter of fact, if you try to start a compose stack that starts with a version number it gives you a warning that it’s not needed.

JollyGreen_sasquatch@sh.itjust.works on 11 Feb 01:04 collapse

The lack of version is the problem. Syntax has changed over time, so when someone finds or has an older compose file, there is no hint it won’t work with the current version of docker-compose until you get errors and no graceful way to handle it.

lambda@programming.dev on 11 Feb 15:45 collapse

I have tried probably over a hundred and never had that happen once. I hear you. But, there is only one version now and if your compose file doesn’t work it’s just incorrect.

BlindFrog@lemmy.world on 10 Feb 21:23 next collapse

I run synology, so I usually refer to this guy’s website first to compare projects mariushosting.com/docker/

Although, some guides he posts require an environment variables file, of which he requires a donation for before downloading. I just scour the internet for the original projects’ compose at that point.

node815@lemmy.world on 11 Feb 04:31 next collapse

I’m not the host or author of this one, but I know it already covers what you are wanting to do. ;)

awesome-docker-compose.com/apps

Kng@feddit.rocks on 11 Feb 07:56 collapse

Not sure how many people would directly seek out a website like this but if it shows up in google searches its probably useful. You could also probably also source compose files from github automatically (obviously with a disclaimer) to help quickly get examples for containers.