Pi-hole System Requirements: RAM, Storage, OS & Ports

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 SQLite database, described on the query database page. Disk retention and in-memory history are separate: database.maxDBdays controls the age of records retained on disk, while FTL imports recent history on startup. Keeping a year of disk history does not mean that entire year is held in RAM. Check list size and actual process memory use when deciding whether the host needs more RAM.

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 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.

Which Raspberry Pi or mini PC should you use?

For a dedicated host, start with a Pi 3B+ you already own or consider a Pi 4 with 2 GB RAM when buying. This is an editorial recommendation based on the published minimum and board specifications. It is not a throughput rating or a guarantee for a particular blocklist size.

The board facts come from Raspberry Pi’s specifications for the Zero 2 W, 3B+, 4 and 5. Match the OS image, power supply and storage accessories to the exact board. A faster board does not change which domains Pi-hole can block.

For a mini PC, choose by compatibility rather than a required processor badge. An Intel N100 is an option, not a Pi-hole requirement. Check that the exact machine can run an actively maintained supported distribution and that its network interface works under that OS. A single network connection is sufficient for a DNS host; it does not need the multiple ports of an inline firewall.

An existing VM or container host avoids buying another box, but reserve resources for Pi-hole and account for host restarts. Two filtering instances on the same physical host still share its outages. Keep a second resolver on an independent host if surviving maintenance is part of the requirement.

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.