Pi-hole Hardware Requirements and What to Buy

Almost every “what hardware do I need for Pi-hole” answer starts in the wrong place, because it starts with the processor. A DNS sinkhole answers small UDP queries from a local database. The work is trivial. What actually decides whether the box is still doing its job in three years is how it stores things, whether it holds a stable address, and whether it stays powered on.

Here is what the project documents, what those numbers leave out, and how to translate that into something you can actually buy or repurpose.

What the project documents as the minimum

The published prerequisites page is short, and worth reading before anything else:

• 512 MB of RAM.
• 2 GB of free disk space, 4 GB recommended.
• A static IP address, though a DHCP reservation on the router counts.
• One of the officially supported operating systems: Alpine, Armbian, Debian, CentOS Stream, Fedora, Raspberry Pi OS, or Ubuntu.

The resolver binary, pihole-FTL, is pre-built for x86_64 (amd64), 32-bit x86 (i686), armv6, armv7, armv8 (aarch64) and riscv64. Anything outside that list means compiling FTL from source, which is a maintenance commitment rather than a one-time cost.

The same page makes the point the name obscures: despite being called Pi-hole, there is no requirement to run it on a Raspberry Pi. Any hardware running a supported OS qualifies.

Why the processor is the least interesting spec

A cached DNS answer is a lookup in a local table and a reply packet. Even a heavily used household network generates a query volume that a decade-old ARM core absorbs without noticing. The visible latency in a home network almost always comes from the upstream resolver or from a cache miss, not from the sinkhole’s own processing.

Two workloads do consume real CPU, and both are periodic rather than constant:

• Gravity rebuilds. The pihole -g process downloads every subscribed list, parses each into a domains-only format, merges, de-duplicates, sorts and writes the result into the gravity table of /etc/pihole/gravity.db. This is documented to run automatically once a week. On a low-end board with many large lists it is a noticeable few minutes, and DNS is reloaded at the end of it.
• Regex evaluation. Every regex filter is applied to queries that are not resolved from the exact-match tables. A handful is free. A long hand-written regex set on a slow core is the one configuration that turns CPU into a real variable.

Neither of those justifies buying a faster machine. They justify keeping the list count sane, which is a configuration decision covered in what a Pi-hole DNS sinkhole can and cannot block.

Memory is a blocklist question, not a hardware question

The documented 512 MB floor assumes a fairly ordinary setup. Memory use scales with two things you control: how many domains gravity has loaded, and how much query history FTL is holding.

FTL keeps recent query data in memory for the dashboard and long-term history in its own database, described on the FTL database page. Longer retention means a larger working set and a larger file on disk. A household that keeps a year of query history and subscribes to several million domains is a materially different machine from one running a default install.

If you are trying to decide between a 512 MB board and a 2 GB one, the honest answer is that the second costs very little more and removes the entire question. The site’s memory and blocklist sizer gives a rough order-of-magnitude estimate from a domain count and a daily query volume, which is enough to tell a 512 MB decision from a 2 GB one. It is an estimator, not a measurement of your install; the number reported by the running FTL process on your own host is always the authority.

Storage endurance is the real buying decision

This is where most Pi-hole deployments eventually fail, and it gets almost no attention in setup guides.

Pi-hole writes continuously by design. Query logging appends to /var/log/pihole/pihole.log, rotated daily where logrotate is present. FTL writes query history into its long-term database. Gravity rewrites gravity.db on every rebuild. None of this is heavy by server standards, but it is constant, and constant small writes are precisely the pattern that wears out cheap flash.

The practical consequences:

• Consumer microSD cards are the wrong medium for a write-in-a-loop workload. They are the default because they are what a Raspberry Pi ships with, not because they suit the job. If a card is the only option, prefer a high-endurance card sold for continuous video recording, and treat it as a consumable.
• Booting from a USB SSD, NVMe, or eMMC removes the problem for the price of the adapter. On any Raspberry Pi model that supports it, this is the single highest-value change to the build.
• A virtual machine or container on an existing always-on host inherits that host’s storage, which is usually already appropriate.

There is a second-order effect worth naming. When the sinkhole is the network’s only resolver, storage failure does not look like storage failure. It looks like the internet being down for everyone in the house, at the least convenient moment, with no obvious cause.

If that is unacceptable, the answer is a second instance rather than better hardware. Two modest resolvers both running the filter beat one careful one, because a single filtering resolver is a single point of failure by definition.

Addressing, ports and network position

Two requirements from the documentation are easy to skip and expensive to skip:

A stable address. Clients are handed the sinkhole’s IP as their DNS server. If that address moves, every device on the network loses name resolution until it moves back. A DHCP reservation on the router satisfies this without touching the host’s config.

Free ports. The prerequisites page lists what pihole-FTL binds:

Port	Protocol	Purpose
53	TCP/UDP	DNS
67	IPv4 UDP	DHCP server (optional)
547	IPv6 UDP	DHCPv6 (optional)
80 / 443	TCP	Web interface, served by FTL itself
123	UDP	NTP server (optional)

Port 53 is the one that bites. Another DNS server already listening on the host, such as BIND or a distribution’s local stub resolver, will prevent Pi-hole from answering at all. The documentation is explicit that the conflicting service has to be turned off. Note also that if something else already holds 80 and 443, FTL attempts 8080 and 8443 instead, and if those are taken too the web interface is simply unavailable until the webserver.port option is set manually.

Wired beats wireless for the host. Not for throughput, which is irrelevant here, but because a resolver that drops off a congested wireless band takes the whole network’s name resolution with it.

Four shapes that work

• A Raspberry Pi, booting from SSD. The default answer, and a good one, provided the storage advice above is followed. Any recent model has ample headroom.
• A small x86 mini PC or repurposed thin client. Often cheaper second-hand than a new Pi with accessories, runs a supported distribution natively, and comes with real storage. Higher idle power draw is the trade.
• A VM or container on an existing hypervisor or NAS. Zero additional hardware, zero additional power, and it inherits existing storage and backups. The caveat is dependency: if the sinkhole and the hypervisor go down together, so does DNS for everything.
• A second, deliberately cheap instance. Redundancy is worth more than specifications. Two 512 MB boards handing out the same filtered answers survive one of them dying.

What not to buy

• Dedicated hardware, if you already own something that is always on. The workload is small enough that adding it to an existing machine is usually the correct engineering answer.
• A large disk. Even generous query retention does not approach the capacity of the smallest sensible drive. Endurance, not capacity, is the metric.
• More cores. They will idle.
• A branded starter kit, unless the convenience is worth the premium to you. The documentation mentions such kits exist; nothing in them is required.

Before you order anything

Check whether the sinkhole will actually see your traffic. Hardware cannot fix a router that refuses to advertise a custom DNS server, a device with a hardcoded resolver, or a client that encrypts its queries and bypasses the network’s settings entirely. Those constraints, and what to do about each, are covered in what a Pi-hole DNS sinkhole can and cannot block and in the diagnostic ladder in Pi-hole not blocking ads.

If you have not settled on Pi-hole yet, the architectural differences that matter are set out in Pi-hole vs AdGuard Home. The hardware answer is close to identical either way, which is itself a useful thing to know before spending money.