---
title: Charmhub | Deploy Pi-hole using Charmhub - The Open Operator Collection
description: Deploy the latest version of Pi-hole on any cloud. Network-wide DNS sinkhole
  and ad blocker for Ubuntu machines.
url: https://charmhub.io/pi-hole
---

# Pi-hole

[Jose Massón](https://charmhub.io/publisher/jose-masson "View all packages from Jose Massón")

* [Jose Massón](https://charmhub.io/publisher/jose-masson "View all packages from Jose Massón")

Platform:

26.04

stable 3

```
juju deploy pi-hole
```

[Learn to deploy on juju >](https://juju.is/docs/juju/manage-applications)

[Read documentation](https://github.com/Abuelodelanada/pi-hole-operator/tree/main/docs)

#### Relevant links

* [Homepage](https://github.com/Abuelodelanada/pi-hole-operator)

---

#### Contacts

* [Submit a bug](https://github.com/Abuelodelanada/pi-hole-operator/issues)

---

Share your thoughts on this charm with the community on discourse.

[Join the discussion](https://discourse.charmhub.io/)

#### Network-wide DNS sinkhole and ad blocker for Ubuntu machines.

Pi-hole is a DNS sinkhole. It answers DNS for a whole network and refuses to
resolve the domains that serve advertisements and trackers, so every device
behind it is filtered without installing anything on the device itself.

This charm deploys and operates Pi-hole v6 on Ubuntu machines — LXD, MAAS, or
a public cloud — using the `pihole-by-rajannpatel` snap. It provides one
optional relation, `cos-agent`: relate it to `opentelemetry-collector` and
the subordinate takes the snap's logs (through its read-only `logs` content
slot) and host metrics, forwarding them to your observability backends.

What the charm does for you:

* Installs the snap at a revision the charm's release defines, held
  against auto-refresh — the snap never updates itself — and starts the
  FTL daemon, which the snap does not start by itself. The admin UI
  serves on 80 and 443, the latter with a self-signed certificate.
* Takes port 53 away from `systemd-resolved` on deployment, and gives
  it back on removal, so the machine is never left without a resolver.
* Closes the NTP server the snap opens on 123/udp by default.
* Generates the admin UI password itself, stores it in a Juju secret,
  and applies it before the daemon ever serves; actions retrieve and
  rotate it. There is no configuration option for the password.
* Reports health from the Pi-hole API, not from the service manager,
  so `active` means "answering queries" — and runs the snap's own
  `snap-check` diagnostic when collecting status on an installed
  unit, so a port conflict or a broken config shows up as `blocked`
  naming the remedy.
* Connects the snap's diagnostic plugs (`system-observe`,
  `hardware-observe`, `mount-observe`, `time-control`,
  `process-control`), keeping FTL's log free of capability warnings.
* Gives the operator escape hatches as actions: `snap-check` (run the
  diagnostic on demand), `update-gravity` (refresh blocklists now,
  optionally a full rebuild), and `free-port-53` (recover the port).
* Optionally sets the blocklist refresh schedule (`gravity-schedule`,
  a systemd `OnCalendar` string) through a host drop-in, because the
  snap cannot manage its own timer.
* Optionally serves DHCP from the FTL server (`dhcp-enabled` and the
  pool options), gated so an unservable pool or an occupied 67/udp
  shows up as `blocked` naming the remedy.

A single unit is the supported shape. Two Pi-holes are two independent
resolvers with independently drifting blocklists, not a cluster.

Note that the underlying snap is **unofficial**: the Pi-hole project does not
support snap-based installations. See this charm's documentation before
deploying it anywhere you care about.