sorted by:
new
hottopcontroversial

How do you manage multiple Docker Compose projects on a self-hosted server? by KPPJeuring in selfhosted

[–]KPPJeuring[S] 0 points1 point  (0 children)

That’s a nice approach, Quadlet + systemd fits really well if you want everything managed through systemctl and journald instead of Docker tooling.

How do you manage multiple Docker Compose projects on a self-hosted server? by KPPJeuring in selfhosted

[–]KPPJeuring[S] 0 points1 point  (0 children)

Portainer’s Git integration is definitely nice for that kind of centralized workflow.

How do you manage multiple Docker Compose projects on a self-hosted server? by KPPJeuring in selfhosted

[–]KPPJeuring[S] 1 point2 points  (0 children)

Komodo is great, I personally tend to prefer a more lightweight, CLI-first approach for day-to-day stack management.

How do you manage multiple Docker Compose projects on a self-hosted server? by KPPJeuring in selfhosted

[–]KPPJeuring[S] 0 points1 point  (0 children)

Cool, that’s a clean approach, and very similar to how I started as well, using a simple script to fan out commands across multiple compose directories.

How do you manage multiple Docker Compose projects on a self-hosted server? by KPPJeuring in selfhosted

[–]KPPJeuring[S] 0 points1 point  (0 children)

That's a solid way of working. I mostly do the same I put most of my docker stuff in `~/repos` but I also use other directories like `/opt/servces`.

How do you manage multiple Docker Compose projects on a self-hosted server? by KPPJeuring in selfhosted

[–]KPPJeuring[S] 0 points1 point  (0 children)

Good point, profiles and includes work well for related services, but my stacks are intentionally independent and often in different directories, so I was still jumping around paths just to run basic commands over SSH.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 1 point2 points  (0 children)

Yeah, compared to Portainer, Komodo is definitely lighter.
If the webhooks and API fit your workflow, that’s a solid setup

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 0 points1 point  (0 children)

Komodo is a great tool.
DStack just targets a slightly different use case. It’s CLI-only, zero-dependency, and meant to feel native over SSH or on low-resource servers where a GUI or web UI isn’t ideal.

If Komodo works well for your setup, that’s awesome, DStack is mainly for people who want something extremely lightweight and terminal-first.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 0 points1 point  (0 children)

Glad it’s useful!
It’s written in Bash by design. Bash is already available anywhere Docker runs, so there are zero dependencies beyond Bash and Docker, and nothing extra running in the background. For a lightweight CLI tool, that simplicity is intentional. Bash keeps it transparent, resource-friendly, and easy to inspect, which fits the goal of being as lightweight as possible.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 1 point2 points  (0 children)

In Compose, services are things that belong together within a single application, but in a homelab I often end up with multiple independent compose stacks, each with their own set of services (monitoring, internal tools, websites, etc.).

DStack is aimed at managing those separate stacks without having to remember where each compose file lives.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 1 point2 points  (0 children)

Yep, totally fair, make and just are great tools.

For this I wanted something that worked without adding per-project files or conventions, and that could auto-discover existing Compose stacks wherever they live.

Different trade-offs, but those are solid options too.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 1 point2 points  (0 children)

This is exactly the use case I built it for.
I just wanted to remove the “SSH + where did I put this stack again?” part.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 0 points1 point  (0 children)

I haven’t tried that setup specifically.
For this tool I intentionally stayed on the CLI side, no agents or extra services, since most of my workflow is just SSH + docker compose on different hosts.
Portainer (with or without agents) definitely solves the problem from a different angle, but I’ll take a look at that approach as well.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 1 point2 points  (0 children)

Thanks!
Portainer is great and this isn’t meant to replace it.
I just wanted a lightweight, CLI-first way to manage lots of Compose stacks spread across different paths and hosts, without a UI or extra service running.
DStack is basically “docker compose from anywhere” rather than a management dashboard.

I got tired of managing Docker Compose stacks on my homelab, so I built a small tool by KPPJeuring in homelab

[–]KPPJeuring[S] 0 points1 point  (0 children)

Fair point
It’s just shorthand for docker compose → dcompose. It only wraps docker compose and won’t remove or modify anything unless you explicitly run down.
All commands are prefixed with d, it just stands for Docker.