On that page, we mention:

with the ability to renew each subsequent year

We plan to have a process for you to renew your license with us before the licenses reach expiry. We are still determining exactly what this process will look like, but the intent is for this license is that it can be renewed at no cost.

You’re using relative paths in your volumes:

volumes:
  - './etc-pihole:/etc/pihole'
  - './etc-dnsmasq.d:/etc/dnsmasq.d'

When using compose from the command line, these volumes would be mounted as bind mounts with relative paths to where you ran the docker compose up command - for example, if you were in /tmp/pihole they would be at /tmp/pihole/etc-pihole and /tmp/pihole/etc-dnsmasq.d. In Portainer, because we run the compose commands from within the Portainer container’s file system rather than on the host environment, the relative path is relative to the Portainer container’s file system.

If these file paths exist on your host filesystem, you could change the relative paths to absolute paths instead:

volumes:
  - /path/to/etc-pihole:/etc/pihole
  - /path/to/etc-dnsmasq.d:/etc/dnsmasq.d

Or, if they don’t exist and are populated by the container image on first deploy, you could create them as named volumes:

services:
  pihole:
    ...
    volumes:
      - etc-pihole:/etc/pihole
      - etc-dnsmasq.d:/etc/dnsmasq.d

volumes:
  etc-pihole:
  etc-dnsmasq.d:

Your method will depend on your requirements and what the image itself expects and provides.

Docker doesn’t allow you to mount a subpath of a named volume - you can only mount the named volume itself:

volumes:
  - my_data:/path/in/container

When mounting an existing volume in a stack file, you will also need to flag that volume as external otherwise it will try to create it for you. This is done in a separate volumes section outside of the services section:

volumes:
  my_data:
    external: true

Do I need to have one Volume for every stack so I would just say my_data:/datastore?

You can share volumes between containers, however I would generally advise a volume for each. This makes the container configurations more independent of each other, whereas shared volumes are less so.

Am I better off just ignoring Volumes and putting my persistent files somewhere like /data/my_data/ ?

It depends. If you only intend to deploy your stack on the one environment and you don’t need the ability to redeploy the stack on another environment, then bind mounts (mounting to a path on the host) are fine. When portability is a concern, named volumes are generally better.

Am I asking the wrong questions :)

No such thing :)