• Using Watchtower? See the Note on Watchtower at the bottom of this readme

• As of 2023.01, if you have any modifications for lighttpd via an external.conf file, this file now needs to be mapped into /etc/lighttpd/conf-enabled/whateverfile.conf instead

• Due to a known issue with Docker and libseccomp <2.5, you may run into issues running 2022.04 and later on host systems with an older version of libseccomp2 (Such as Debian/Raspbian buster or Ubuntu 20.04, and maybe CentOS 7).

  The first recommendation is to upgrade your host OS, which will include a more up to date (and fixed) version of libseccomp.

  If you absolutely cannot do this, some users have reported success in updating libseccomp2 via backports on debian, or similar via updates on Ubuntu. You can try this workaround at your own risk (Note, you may also find that you need the latest docker.io (more details here)

• Some users have reported issues with using the --privileged flag on 2022.04 and above. TL;DR, don't use that mode, and be explicit with the permitted caps (if needed) instead

1. Copy docker-compose.yml.example to docker-compose.yml and update as needed. See example below: Docker-compose example:

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "80:80/tcp"
    environment:
      TZ: 'America/Chicago'
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
    restart: unless-stopped

2. Run docker compose up -d to build and start pi-hole (Syntax may be docker-compose on older systems)
3. Use the Pi-hole web UI to change the DNS settings Interface listening behavior to "Listen on all interfaces, permit all origins", if using Docker's default bridge network setting. (This can also be achieved by setting the environment variable DNSMASQ_LISTENING to all)

Here is an equivalent docker run script.

A Docker project to make a lightweight x86 and ARM container with Pi-hole functionality.

1. Install docker for your x86-64 system or ARMv7 system using those links. Docker-compose is also recommended.
2. Use the above quick start example, customize if desired.
3. Enjoy!

This container uses 2 popular ports, port 53 and port 80, so may conflict with existing applications ports. If you have no other services or docker containers using port 53/80 (if you do, keep reading below for a reverse proxy example), the minimum arguments required to run this container are in the script docker_run.sh

If you're using a Red Hat based distribution with an SELinux Enforcing policy add :z to line with volumes like so:

    -v "$(pwd)/etc-pihole:/etc/pihole:z" \
    -v "$(pwd)/etc-dnsmasq.d:/etc/dnsmasq.d:z" \

Volumes are recommended for persisting data across container re-creations for updating images. The IP lookup variables may not work for everyone, please review their values and hard code IP and IPv6 if necessary.

You can customize where to store persistent data by setting the PIHOLE_BASE environment variable when invoking docker_run.sh (e.g. PIHOLE_BASE=/opt/pihole-storage ./docker_run.sh). If PIHOLE_BASE is not set, files are stored in your current directory when you invoke the script.

Automatic Ad List Updates - since the 3.0+ release, cron is baked into the container and will grab the newest versions of your lists and flush your logs. Set your TZ environment variable to make sure the midnight log rotation syncs up with your timezone's midnight.

There are multiple different ways to run DHCP from within your Docker Pi-hole container but it is slightly more advanced and one size does not fit all. DHCP and Docker's multiple network modes are covered in detail on our docs site: Docker DHCP and Network Modes

There are other environment variables if you want to customize various things inside the docker container:

While these may still work, they are likely to be removed in a future version. Where applicable, alternative variable names are indicated. Please review the table above for usage of the alternative variables

To use these env vars in docker run format style them like: -e DNS1=1.1.1.1

Here is a rundown of other arguments for your docker-compose / docker run.

• A good way to test things are working right is by loading this page: http://pi.hole/admin/
• How do I set or reset the Web interface Password?
  • docker exec -it pihole_container_name pihole -a -p - then enter your password into the prompt
• Port conflicts? Stop your server's existing DNS / Web services.
  • Don't forget to stop your services from auto-starting again after you reboot
  • Ubuntu users see below for more detailed information
• You can map other ports to Pi-hole port 80 using docker's port forwarding like this -p 8080:80 if you are using the default blocking mode. If you are using the legacy IP blocking mode, you should not remap this port.
  • Here is an example of running with nginxproxy/nginx-proxy (an nginx auto-configuring docker reverse proxy for docker) on my port 80 with Pi-hole on another port. Pi-hole needs to be DEFAULT_HOST env in nginxproxy/nginx-proxy and you need to set the matching VIRTUAL_HOST for the Pi-hole's container. Please read nginxproxy/nginx-proxy readme for more info if you have trouble.
• Docker's default network mode bridge isolates the container from the host's network. This is a more secure setting, but requires setting the Pi-hole DNS option for Interface listening behavior to "Listen on all interfaces, permit all origins".

Modern releases of Ubuntu (17.10+) and Fedora (33+) include systemd-resolved which is configured by default to implement a caching DNS stub resolver. This will prevent pi-hole from listening on port 53. The stub resolver should be disabled with: sudo sed -r -i.orig 's/#?DNSStubListener=yes/DNSStubListener=no/g' /etc/systemd/resolved.conf

This will not change the nameserver settings, which point to the stub resolver thus preventing DNS resolution. Change the /etc/resolv.conf symlink to point to /run/systemd/resolve/resolv.conf, which is automatically updated to follow the system's netplan: sudo sh -c 'rm /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf' After making these changes, you should restart systemd-resolved using systemctl restart systemd-resolved

Once pi-hole is installed, you'll want to configure your clients to use it (see here). If you used the symlink above, your docker host will either use whatever is served by DHCP, or whatever static setting you've configured. If you want to explicitly set your docker host's nameservers you can edit the netplan(s) found at /etc/netplan, then run sudo netplan apply. Example netplan:

network:
    ethernets:
        ens160:
            dhcp4: true
            dhcp4-overrides:
                use-dns: false
            nameservers:
                addresses: [127.0.0.1]
    version: 2

Note that it is also possible to disable systemd-resolved entirely. However, this can cause problems with name resolution in vpns (see bug report). It also disables the functionality of netplan since systemd-resolved is used as the default renderer (see man netplan). If you choose to disable the service, you will need to manually set the nameservers, for example by creating a new /etc/resolv.conf.

Users of older Ubuntu releases (circa 17.04) will need to disable dnsmasq.

@Rikj000 has produced a guide to assist users installing Pi-hole on Dokku

The primary docker tags are explained in the following table. Click here to see the full list of tags. See GitHub Release notes to see the specific version of Pi-hole Core, Web, and FTL included in the release.

The Date-based (including incremented "Patch" versions) do not relate to any kind of semantic version number, rather a date is used to differentiate between the new version and the old version, nothing more. Release notes will always contain full details of changes in the container, including changes to core Pi-hole components

The standard Pi-hole customization abilities apply to this docker, but with docker twists such as using docker volume mounts to map host stored file configurations over the container defaults. However, mounting these configuration files as read-only should be avoided. Volumes are also important to persist the configuration in case you have removed the Pi-hole container which is a typical docker upgrade pattern.

Do not attempt to upgrade (pihole -up) or reconfigure (pihole -r). New images will be released for upgrades, upgrading by replacing your old container with a fresh upgraded image is the 'docker way'. Long-living docker containers are not the docker way since they aim to be portable and reproducible, why not re-create them often! Just to prove you can.

0. Read the release notes for both this Docker release and the Pi-hole release
   • This will help you avoid common problems due to any known issues with upgrading or newly required arguments or variables
   • We will try to put common break/fixes at the top of this readme too
1. Download the latest version of the image: docker pull pihole/pihole
2. Throw away your container: docker rm -f pihole
   • Warning When removing your pihole container you may be stuck without DNS until step 3; docker pull before docker rm -f to avoid DNS interruption OR always have a fallback DNS server configured in DHCP to avoid this problem altogether.
   • If you care about your data (logs/customizations), make sure you have it volume-mapped or it will be deleted in this step.
3. Start your container with the newer base image: docker run <args> pihole/pihole (<args> being your preferred run volumes and env vars)

Why is this style of upgrading good? A couple reasons: Everyone is starting from the same base image which has been tested to known it works. No worrying about upgrading from A to B, B to C, or A to C is required when rolling out updates, it reduces complexity, and simply allows a 'fresh start' every time while preserving customizations with volumes. Basically I'm encouraging phoenix server principles for your containers.

To reconfigure Pi-hole you'll either need to use an existing container environment variables or if there is no a variable for what you need, use the web UI or CLI commands.

Here are some relevant wiki pages from Pi-hole's documentation. The web interface or command line tools can be used to implement changes to pihole.

We install all pihole utilities so the the built in pihole commands will work via docker exec <container> <command> like so:

• docker exec pihole_container_name pihole updateGravity
• docker exec pihole_container_name pihole -w spclient.wg.spotify.com
• docker exec pihole_container_name pihole -wild example.com

The webserver and DNS service inside the container can be customized if necessary. Any configuration files you volume mount into /etc/dnsmasq.d/ will be loaded by dnsmasq when the container starts or restarts or if you need to modify the Pi-hole config it is located at /etc/dnsmasq.d/01-pihole.conf. The docker start scripts runs a config test prior to starting so it will tell you about any errors in the docker log.

Similarly for the webserver you can customize configs in /etc/lighttpd

As long as your docker system service auto starts on boot and you run your container with --restart=unless-stopped your container should always start on boot and restart on crashes. If you prefer to have your docker container run as a systemd service instead, add the file pihole.service to "/etc/systemd/system"; customize whatever your container name is and remove --restart=unless-stopped from your docker run. Then after you have initially created the docker container using the docker run command above, you can control it with "systemctl start pihole" or "systemctl stop pihole" (instead of docker start/docker stop). You can also enable it to auto-start on boot with "systemctl enable pihole" (as opposed to --restart=unless-stopped and making sure docker service auto-starts on boot).

NOTE: After initial run you may need to manually stop the docker container with "docker stop pihole" before the systemctl can start controlling the container.

DNSMasq / FTLDNS expects to have the following capabilities available:

• CAP_NET_BIND_SERVICE: Allows FTLDNS binding to TCP/UDP sockets below 1024 (specifically DNS service on port 53)
• CAP_NET_RAW: use raw and packet sockets (needed for handling DHCPv6 requests, and verifying that an IP is not in use before leasing it)
• CAP_NET_ADMIN: modify routing tables and other network-related operations (in particular inserting an entry in the neighbor table to answer DHCP requests using unicast packets)
• CAP_SYS_NICE: FTL sets itself as an important process to get some more processing time if the latter is running low
• CAP_CHOWN: we need to be able to change ownership of log files and databases in case FTL is started as a different user than pihole

This image automatically grants those capabilities, if available, to the FTLDNS process, even when run as non-root.
By default, docker does not include the NET_ADMIN capability for non-privileged containers, and it is recommended to explicitly add it to the container using --cap-add=NET_ADMIN.
However, if DHCP and IPv6 Router Advertisements are not in use, it should be safe to skip it. For the most paranoid, it should even be possible to explicitly drop the NET_RAW capability to prevent FTLDNS from automatically gaining it.

We have noticed that a lot of people use Watchtower to keep their Pi-hole containers up to date. For the same reason we don't provide an auto-update feature on a bare metal install, you should not have a system automatically update your Pi-hole container. Especially unattended. As much as we try to ensure nothing will go wrong, sometimes things do go wrong - and you need to set aside time to manually pull and update to the version of the container you wish to run. The upgrade process should be along the lines of:

• Important: Read the release notes. Sometimes you will need to make changes other than just updating the image
• Pull the new image
• Stop and remove the running Pi-hole container
  • If you care about your data (logs/customizations), make sure you have it volume-mapped or it will be deleted in this step.
• Recreate the container using the new image

Pi-hole is an integral part of your network, don't let it fall over because of an unattended update in the middle of the night.

Please report issues on the GitHub project when you suspect something docker related. Pi-hole or general docker questions are best answered on our user forums.