Not for PiHole but I was testing this recently with traefik. This has a bunch of traefik stuff in there (I’m on mobile so it’s too hard to edit it) but hopefully you see how the networks work

# Testing macvlan setup for traefik
# Will only work on linux because of macvlan network

version: '3'

services:
  traefik-whoami:
    image: traefik/whoami
    container_name: traefik_whoami
    networks:
      - bridge_network
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`whoami.test`)"
      - "traefik.http.routers.whoami.entrypoints=http"
  
  traefik-reverse-proxy:
    image: traefik:v2.10
    container_name: traefik_reverse_proxy
    command:
      - "--api.insecure=true"  # Enable the API dashboard (insecure for testing)
      - "--providers.docker=true"  # Enable Docker provider
      - "--providers.docker.exposedbydefault=false"  # Disable exposing all containers by default
      - "--entrypoints.http.address=:80"  # HTTP entrypoint
      - "--entrypoints.http.forwardedheaders.insecure=true"  # Insecure forwarding (for testing)
      - "--providers.docker.network=bridge_network"  # Use bridge network for traefik discovery
    ports:
      - "1180:80"  # Expose HTTP entrypoint
      - "12345:8080"  # Expose Traefik dashboard
    networks:
      bridge_network: {}
      macvlan_network:
        ipv4_address: 192.168.1.69
    volumes:
      # TODO: Use docker.sock proxy instead of mounting directly
      # https://github.com/Tecnativa/docker-socket-proxy
      - /var/run/docker.sock:/var/run/docker.sock:ro
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.reverse-proxy.rule=Host(`traefik.test`)"
      - "traefik.http.routers.reverse-proxy.entrypoints=http"

networks:
  bridge_network:
    driver: bridge

  macvlan_network:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1
          ip_range: 192.168.1.69/32  # Must be outside router's DHCP range

Why not? You can just connect the PiHole container to both networks and inter-container communication should work as usual. I haven’t tried this with PiHole specifically but I’ve done it with other services in the past

A tale as old as tech

Fair enough! Do you cover your costs for it? I see you’ve got live stats - what’s your monitoring stack?

This is just really cool, I’d love to build an actually useful service like this and have it at least pay for itself but so many things are so daunting! (Payments, SRE, having a nice front end, …)

Wow really nice project! Do you work on this full time?

How did you configure the rainbow text colors? I love the look (I’m on heimdall atm)

some esoteric devices and plugins don’t support them. In fact, some don’t even support HTTP POST properly and will only be able to put form parameters in the URL query string (though you still need to insist on requiring a proper POST method, don’t be an animal).

This gave me a chuckle. Good, practical advice for smaller APIs. Bigger orgs are likely to have distributed tracing etc but for a one man show it’s good to have input on what’s proved actually useful and necessary.

To be fair a lot of ORMs provide updated_at or similar, so if you have a RESTful API you could just take that, or the max of all of them if you’re doing a more complex query. It might be a bit suboptimal but it shouldn’t be too expensive.

Now you can make use of the If-Modified-Since header. Return 304-not-modified if the data hasn’t changed. Now you can intelligently utilise the the client’s caching capability without sacrificing visibility and control. Using this header will let you serve new content instantly and also cache indefinitely. The best of both worlds.

This would’ve been a great spot for an example

Feels like you could maybe (ab)use an ML experiment tracking tool for this, something like MLFlow. Except instead of training an ML model you just trigger your tests and report the statistics from those back to the tracking tool.