To build a Pi-hole ad blocker on a Raspberry Pi 4 in 2026, flash Raspberry Pi OS Lite to a USB SSD, boot the Pi from it, install Pi-hole via the official one-line installer, add Unbound as a local recursive resolver, and set your router's DHCP to hand out the Pi's IP as the only DNS server. The result is a network-wide ad and tracker sinkhole that costs roughly $100 in parts and idles under five watts.
What you'll need checklist: Pi 4 8GB, SSD or quality storage, power, network
Before you flash a single byte, gather the bill of materials. A successful Pi-hole + Unbound build in 2026 hinges on three things: a Pi with enough headroom to run more than one container, durable storage that won't corrupt after six months of small writes, and a stable power supply that won't trigger undervoltage warnings during peak query load.
- A Raspberry Pi 4 Model B 8GB board. The 8GB SKU is the canonical "home server" Pi because it leaves room for Pi-hole, Unbound, Home Assistant, and a reverse proxy on the same box without swapping. Per the Raspberry Pi 4 product page, the board pairs a 1.8 GHz quad-core Cortex-A72 with Gigabit Ethernet and dual-band Wi-Fi.
- A 1TB SATA SSD such as the Crucial BX500 1TB SATA SSD inside a USB 3.0 enclosure, or a 64GB+ A2-rated microSD card if you absolutely must go cheap. The SSD is strongly recommended for log durability — covered in detail below.
- The official 5.1V/3A USB-C PSU (or a vetted equivalent). The Pi 4 throttles aggressively and posts undervoltage warnings to the kernel log if it sees anything less, and Pi-hole's query latency suffers as soon as the CPU clocks down.
- A short Cat6 Ethernet cable. Wi-Fi works in a pinch, but a wired DNS sinkhole is one less variable to chase when the network feels slow at 9 p.m.
- A microSD card (any cheap 8GB+ card) to perform the initial USB-boot flash from Raspberry Pi Imager, if your Pi is older than the 2020 USB-boot-capable bootloader.
- An open router admin login. You will be changing DHCP DNS options at the end of the build, and locked-down ISP routers are the single most common reason a Pi-hole install "doesn't seem to block anything".
Editorial intro: network-wide ad-blocking and the privacy case for self-hosted DNS
Browser-level ad blockers stop at the browser. They do nothing for the smart TV in the living room that phones home every 90 seconds, the Android tablet streaming a kids' app, the printer beaconing telemetry, or the IoT bulb checking in with a Shenzhen subdomain. As of 2026, the average household has 16-plus connected devices, and most ship with no extension API, no DNS-over-HTTPS toggle, and no ad-block awareness whatsoever. A network-wide DNS sinkhole — a service that answers "this domain does not exist" for known ad and tracker hosts before any device on the LAN ever opens a TCP connection — is the only intervention that covers the whole estate at once.
That is Pi-hole's job. Per the official Pi-hole documentation, Pi-hole is a Linux network-level advertisement and Internet tracker blocking application that acts as a DNS sinkhole and optionally a DHCP server, intended for use on a private network. It runs on modest hardware — including a Raspberry Pi — and uses a constantly updated set of community blocklists called "gravity" to decide which domains to refuse.
The privacy half of the build is Unbound. Pi-hole resolves cache misses by forwarding to an upstream — most installers default to Cloudflare 1.1.1.1, Google 8.8.8.8, or Quad9. That works, but it hands your entire household browsing pattern to a single third party. Per NLnet Labs, the maintainer of Unbound, Unbound is a validating, recursive, caching DNS resolver designed for speed and standards compliance. Pointed at the root servers directly, it removes the third-party upstream from the equation. Your Pi talks to the .com TLD servers, then to the authoritative server for the domain you asked about, then caches the answer. No 1.1.1.1, no 8.8.8.8, no opaque logging policy at a hyperscaler.
The combination is the textbook self-hosted DNS stack in 2026: Pi-hole for blocking, Unbound for the recursive lookup. Both are open source, both are well documented, and both fit comfortably inside a Pi 4 8GB with room left over for a couple of Docker containers.
Key Takeaways
- Pi-hole + Unbound on a Raspberry Pi 4 8GB blocks ad, tracker, and telemetry domains for every device on your LAN — phones, smart TVs, printers, IoT — not just browsers.
- Idle resource use is trivial. Per the Pi-hole docs, the FTL daemon and the dnsmasq fork it ships with are lightweight enough to run on a Pi Zero; on a Pi 4 8GB you'll see well under 5% CPU and a few hundred MB of RAM under normal household load.
- Boot from an SSD over USB 3.0. Pi-hole's long-term query database does enough small writes to cook a microSD card inside a year. As of 2026, a 1TB SATA SSD in a USB 3 enclosure is roughly $55 and will outlast the Pi.
- Unbound replaces the upstream DNS forwarder with a local recursive resolver. No 1.1.1.1, no 8.8.8.8 — your Pi asks the root servers directly and caches the answers.
- Plan on 90,000-180,000 daily DNS queries from a typical 10-device household, with 20-40% blocked by gravity blocklists out of the box, per ranges reported across the Pi-hole community dashboard documentation linked below.
What does Pi-hole + Unbound actually do?
Pi-hole is a DNS sinkhole. When a device on your LAN asks "what is the IP for ads.example.com?", the request goes to the Pi instead of your ISP. The Pi looks the domain up against gravity — a merged set of crowd-curated blocklists pulled fresh on a schedule — and if the domain matches, the Pi answers 0.0.0.0 or NXDOMAIN. The device gives up, the ad never loads, the page renders faster, and your bandwidth bill drops a measurable amount over the course of a month. Per the Pi-hole documentation, the project bundles a hardened dnsmasq fork called FTL (Faster Than Light), a SQLite-backed query database, a PHP admin dashboard, and the gravity engine that merges blocklists.
Unbound is the second half. By default, Pi-hole forwards allowed queries (the ones that didn't hit gravity) to an external DNS server. That's fine for blocking, but you've replaced one third party watching your browsing (the ISP) with another (Cloudflare, Google, Quad9). Per NLnet Labs, Unbound is a validating, recursive, caching DNS resolver — meaning it walks the DNS hierarchy itself from the root servers down and caches every answer locally. Once Pi-hole is configured to use 127.0.0.1#5335 (Unbound's local socket) as its upstream, no third-party resolver sees your traffic at all. DNSSEC validation gets handled by Unbound, so signed responses are verified end-to-end.
The two together produce a stack with one inbound dependency — the 13 root servers, which are operated by a federation of organizations rather than a single corporation — and zero outbound resolver dependency. That is the privacy story.
Is the Raspberry Pi 4 8GB overkill or just right?
Strictly speaking, Pi-hole + Unbound is overkill for a Pi 4 8GB. Pi-hole's own documentation lists minimum requirements that a Pi Zero W satisfies. So why the 8GB board? Because a Pi-hole rig is the gateway drug to a home server, and the 8GB SKU is the only Pi 4 variant that comfortably co-hosts Pi-hole, Unbound, Home Assistant, Jellyfin (audio only), a WireGuard endpoint, and a reverse proxy without thrashing.
Per the Raspberry Pi 4 Model B product page, the board ships with a Broadcom BCM2711 quad-core Cortex-A72 at 1.8 GHz, true Gigabit Ethernet (not over the USB bus, unlike the Pi 3B+), USB 3.0 for SSD boot, and up to 8GB LPDDR4-3200. None of that is necessary for DNS alone; all of it is welcome the moment you add a second service.
A representative resource footprint, based on public community measurements and the Pi-hole admin dashboard documentation:
| Service | Idle RAM | Peak RAM | Idle CPU | Notes |
|---|---|---|---|---|
| Pi-hole FTL | ~80 MB | ~180 MB | <2% | scales with query rate and gravity size |
| Unbound | ~40 MB | ~120 MB | <1% | cache grows over weeks of uptime |
| lighttpd + PHP admin | ~30 MB | ~70 MB | negligible | only active when dashboard is open |
| Raspberry Pi OS Lite | ~120 MB | ~150 MB | <1% | headless base |
| Headroom remaining (8GB board) | ~7.6 GB | — | — | for additional containers |
A Pi 4 4GB would handle Pi-hole + Unbound forever without issue. The 8GB exists so the same box can quietly absorb the next three projects you talk yourself into. As of 2026, the price delta between the 4GB and 8GB Pi 4 boards has narrowed to roughly $15-25 at most retailers, which makes the larger variant the obvious choice for any always-on build.
Step-by-step: install Pi-hole, add Unbound, point your router
The official Pi-hole install is one command and a curses-style wizard. Per the documentation, this is the supported install path on Raspberry Pi OS Lite. The full sequence below assumes a fresh Pi 4 8GB with USB-boot enabled and the Crucial BX500 1TB SATA SSD in a UASP-compatible USB 3 enclosure.
- Flash Raspberry Pi OS Lite (64-bit, 2026 release) to the SSD using Raspberry Pi Imager on a desktop. Use the gear icon to set the hostname (
pihole), enable SSH, set a strong password, and pre-load your Wi-Fi credentials if Ethernet is not yet wired. - First boot the Pi from the SSD. Confirm
uname -areports the 64-bit kernel anddf -hshows the SSD as root. Runsudo apt update && sudo apt full-upgrade -yand reboot. - Give the Pi a static IP on your LAN. Either reserve the lease in your router's DHCP table (preferred — survives a re-flash) or set a static address in
/etc/dhcpcd.conf. Pick something outside your DHCP pool, for example192.168.1.53. - Install Pi-hole with the documented one-liner:
curl -sSL https://install.pi-hole.net | bash. Follow the wizard. When asked for an upstream DNS provider, pick Cloudflare temporarily — you'll replace it with Unbound shortly. Note the admin password the installer prints at the end. - Install Unbound as a system package:
sudo apt install -y unbound. Per NLnet Labs, Unbound ships in Debian's main repository and the Raspberry Pi OS package mirrors it directly. - Configure Unbound as a local recursive resolver listening on port 5335. Drop a config at
/etc/unbound/unbound.conf.d/pi-hole.confbased on the example in the official Pi-hole documentation linked above — bind to127.0.0.1@5335, enableharden-dnssec-stripped, setcache-min-ttl: 300, and pre-load the root hints.sudo systemctl restart unbound. - Point Pi-hole at Unbound. In the Pi-hole admin UI under Settings → DNS, uncheck every upstream provider and set the Custom 1 (IPv4) field to
127.0.0.1#5335. Save. Rundig pi-hole.net @127.0.0.1from the Pi to confirm Unbound is answering. - Update your router's DHCP to advertise the Pi as the only DNS server. This is the step people skip and then wonder why "nothing is blocked". In your router admin, set the DNS server option to
192.168.1.53(or whatever static IP you assigned) and remove any secondary public DNS. Reboot one device and confirm in the Pi-hole dashboard that queries from it appear. - Optional but recommended: run Pi-hole and Unbound in Docker. A
docker-compose.ymlthat publishes UDP/TCP 53, mounts persistent volumes for/etc/piholeand/etc/dnsmasq.d, and exposes the dashboard on port 80 keeps the host OS clean and makes upgrades a singledocker compose pull && docker compose up -d. The Pi-hole project publishes an official image, documented in the same docs site linked above.
Once the dashboard at http://pi.hole/admin shows queries flowing and a blocked-percentage above zero, the build is complete.
Why store the database on an SSD, not the microSD card?
Pi-hole writes a row to its SQLite query database on every DNS lookup. A typical 10-device household generates 90,000 to 180,000 queries per day, per the ranges reported in the Pi-hole admin dashboard docs. That's somewhere between 30 and 65 million small writes per year, all landing on the same handful of flash blocks.
Consumer microSD cards are not designed for that workload. They have no DRAM cache, weak wear-leveling, and the lowest-grade flash silicon in the industry. Even an A2-rated card will start throwing read errors inside 12-18 months in this duty cycle, and "throwing read errors" on the boot device means the Pi-hole dashboard suddenly returns 500s and your whole network falls back to whatever secondary DNS the router still remembers.
A USB 3.0 SSD solves the problem completely. The Crucial BX500 1TB SATA SSD is a budget consumer SSD — not the fastest drive on the market — but it has real wear-leveling, real over-provisioning, and a TBW endurance rating that absorbs decades of Pi-hole workload before getting close. As of 2026, the BX500 1TB sits in the $50-65 range at major retailers, which is roughly the same as a high-endurance 256GB microSD card and an order of magnitude more durable.
Two practical notes. First, the USB 3 enclosure matters: use one with a UASP-capable bridge chip (JMS580, ASM235CM, or VL716). Older USB-mass-storage-only bridges cap the Pi 4's effective throughput at roughly 30 MB/s and occasionally hang under sustained writes. Second, you don't need 1TB for Pi-hole alone — you need it for everything else you'll inevitably co-host on the box. The Pi-hole long-term query database itself stays under a gigabyte for years.
Measured impact: query volume, blocked percentage, latency
Public measurements reported in the Pi-hole documentation and community dashboards consistently land in roughly the same ranges for a typical household setup. The table below summarizes representative numbers — every install varies with device count, blocklist choice, and household browsing pattern.
| Metric | Representative range | Source |
|---|---|---|
| Daily DNS queries (10 devices, mixed use) | 90,000 – 180,000 | Pi-hole docs dashboard reference |
| Blocked percentage with default gravity lists | 20% – 40% | Pi-hole docs |
| Blocked percentage with aggressive community lists | 40% – 55% | community reports linked from docs |
| Cache hit ratio after one week of uptime (Unbound) | 70% – 85% | NLnet Labs Unbound documentation |
| First-resolution latency (cold cache, Unbound recursive) | 100 – 300 ms | NLnet Labs Unbound documentation |
| Cached resolution latency | 1 – 5 ms | NLnet Labs Unbound documentation |
| Pi 4 8GB idle power draw (with SSD, no display) | ~3.5 – 5.0 W | Raspberry Pi 4 Model B product page |
The latency line is the one users worry about and shouldn't. Once Unbound's cache is warm — within hours, not days — over 75% of household queries are answered in single-digit milliseconds. Only first-time lookups of brand-new domains pay the recursive penalty, and even those are inside 300 ms. Page load times are typically faster after a Pi-hole install, not slower, because every blocked ad and tracker request is a TCP connection that never opens.
Bottom line: the always-on, low-power privacy upgrade
Per the cited sources, a Pi-hole + Unbound rig on a Raspberry Pi 4 Model B 8GB is the highest-leverage privacy and quality-of-life upgrade you can make to a home network in 2026 for under $150 in parts. It blocks ads and trackers on every device, keeps your DNS resolution off third-party servers, draws under five watts, and runs unattended for years if you put the database on the Crucial BX500 1TB SATA SSD instead of a microSD card. Pair it with the official Raspberry Pi USB-C power supply and you're done.
If you don't need the headroom for additional services, a Pi Zero 2 W is a viable lighter-load alternative — Pi-hole runs comfortably on it for a single-household DNS sinkhole, though Unbound's cache pressure and the cost of co-hosting anything else push most builders toward the Pi 4 anyway. The 8GB board future-proofs the build for the next three projects you'll inevitably add.
Related guides
- Raspberry Pi 4 home server starter guides on SpecPicks
- Self-hosted DNS and privacy stack overviews
- USB-SSD-boot setup walkthroughs for the Pi 4
- Home network segmentation and IoT VLAN primers
- WireGuard endpoint builds on a Pi 4
Citations and sources
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
