Add possibility for Automatic Service Discovery

[MissingDLL]

Description

It would be nice to have homarr to perform a automatic service discovery for Docker-Containers. My sugesstion would be to add docker labels to the container and use these to fill the dashboard. Homepage does this for example in the following way: `labels:

• homepage.group=Media
• homepage.name=Emby
• homepage.icon=emby.png
• homepage.href=http://emby.home/
• homepage.description=Media server` It would be nice, to also set configure the integrations with the labels.

Priority

Medium (Would be very useful)

[mgite]

This is the only thing that stops me from replacing homepage by homarr. It's such a great feature. I use labels to configure Traefic, Whatsupdocker and homepage. I like homarrs integration in arr services and would love to use it, but without this feature i am not going to use homarr.

[ajnart]

I guess we could do that, we planned to do it without tags at all. But isn’t that adding a lot of configuration to your docker file for not a lot of added benefits ?

[mgite]

I guess we could do that, we planned to do it without tags at all. But isn’t that adding a lot of configuration to your docker file for not a lot of added benefits ?

That is what docker compose is for. You have configurations in it and only data in volumes. Infrastructure as Code (IaC) GREAT way to go. In fact when i heard homarr had docker integration i thought about this first and i was surprised when i found out you still had to manually configure things just like in dashboards without docker integration.

EDIT: I also forgot to mention another good feature, since you are already mounting docker socket it could also have auto discovery just like homepage does.

[MissingDLL]

Has someone already started working on this topic. I guess i could help with setting this up.

[polarathene]

But isn’t that adding a lot of configuration to your docker file for not a lot of added benefits ?

You can keep it separate as a complimentary yaml if it were to add too much noise. Main benefit is that configuration is bundled with the container service, which some prefer for service discovery elsewhere (Traefik / CDP, AutoKuma, etc).

It makes more sense if the containers are not config and forget, any changes for integrated services is centralized to each service and you could say it's more portable / convenient to share a service that way where integrations get auto configured. Then if the service is ever removed/replaced those integrations don't have additional config to remember to go modify.

Tends to be more verbose, so there's a trade-off but it's nice to have the flexibility.

---

You can see a brief example here: https://github.com/lucaslorentz/caddy-docker-proxy/issues/652#issuecomment-2320412566

A separate compose.yaml has some services with labels for routing the reverse-proxy (Caddy) to the containers, and other labels for Homepage to handle navigation.

• I could also start another compose.yaml project with different services, adding the metadata labels and then those new services will become routable via Caddy with certs and easy navigation via a dashboard like Homepage.
• I could just share these compose.yaml to someone else running the separate compose.yaml for reverse-proxy + homepage and they'll get to try those new services automatically configured for a dashboard instead of any extra manual work.

I haven't looked into Homarr much, so not sure if it offers anything as simple for modular/ephemeral configuration perks like could be done with the labels approach.

---

For reference without visiting the link, here are the two compose.yaml that show off the feature:

Click to view (main compose.yaml)

```yaml # For other `compose.yaml` to connect through CDP: network: default: name: proxy-net services: reverse-proxy: image: lucaslorentz/caddy-docker-proxy:2.9 volumes: - /var/run/docker.sock:/var/run/docker.sock ports: - "80:80" - "443:443" homepage: image: ghcr.io/gethomepage/homepage:v0.9.6 volumes: - /var/run/docker.sock:/var/run/docker.sock configs: - source: homepage-settings target: /app/config/settings.yaml - source: homepage-docker target: /app/config/docker.yaml # Workaround: Skips copying unwanted demo configs: - source: empty target: /app/config/bookmarks.yaml - source: empty target: /app/config/services.yaml - source: empty target: /app/config/widgets.yaml labels: caddy: localhost caddy.reverse_proxy: "{{upstreams 3000}}" # Embedding small config files into `compose.yaml` instead of mounting via `volumes`: # NOTE: This requires a Docker Compose release from 2024+ configs: homepage-settings: content: | headerStyle: boxedWidgets layout: example: style: row columns: 4 homepage-docker: content: | my-docker: socket: /var/run/docker.sock empty: content: | # Empty ```

Click to view (your services compose.yaml)

```yaml network: default: name: proxy-net external: true services: # Several service examples with labels for adding `homepage` metadata: example-a: image: caddy:2.8 environment: SOME_ENV_HERE: world configs: - source: hello-env target: /etc/caddy/Caddyfile labels: caddy: hello-world.localhost caddy.reverse_proxy: "{{upstreams 80}}" homepage.href: https://hello-world.localhost homepage.name: Hello World homepage.description: Basic example with Caddy homepage.icon: caddy homepage.group: Example example-b: image: caddy:2.8 environment: SOME_ENV_HERE: DMS configs: - source: hello-env target: /etc/caddy/Caddyfile labels: caddy: hello-dms.localhost caddy.reverse_proxy: "{{upstreams 80}}" homepage.href: https://hello-dms.localhost homepage.name: Hello DMS homepage.description: Basic example with Caddy homepage.icon: docker-mailserver homepage.group: Example example-c: image: traefik/whoami labels: caddy: whoami.localhost caddy.reverse_proxy: "{{upstreams 80}}" homepage.href: https://whoami.localhost homepage.name: Whoami? homepage.description: Diagnostics check homepage.icon: traefik homepage.group: Example configs: hello-env: content: | :80 { respond "Hello {env.SOME_ENV_HERE}!" } ```

FWIW, with compose.yaml at least, labels can easily be given multi-line content like a config file, similar to how is shown in the configs sections with content: |.

I've not seen that used anywhere though, so the per key approach like shown above may still be required for broader compatibility.