Pi-hole plus VPN on one Pi: is the OS still supported?

Two things get mixed up on a combined Pi-hole and VPN box: the distribution family you installed and the release plus architecture the components actually support. A board that boots an image proves the kernel runs; it does not prove that Pi-hole's FTL binary and your VPN installer target the same userspace. The real test is a four-way overlap of board support, release branch, package architecture and an upgrade path you can drive yourself. Lose any one leg and the appliance works this week, then strands you at the next security update.

The release branch sets support, not the family name

Ask which release the project still tests against, then write the answer down as a version string rather than "Debian". Pi-hole's prerequisites page lists supported operating systems and prebuilt FTL architectures as two separate requirements, limits support to releases the distribution itself still maintains, and warns that variants or unusual configurations can fail even inside the supported list. That phrasing matters: a supported family does not cover every member of it.

An old image that still boots on your Pi is not evidence of support. The board is fine, the package index is stale, and the mismatch surfaces later, when an installer pulls a dependency the release can no longer satisfy.

The VPN side has more parts, each with its own window: the tunnel daemon, the install helper that writes its configuration, the provider's client app and the distribution's integration package are four separate projects. An installer that recognises your distribution and an installer that produces a service the release can keep running are different claims. Look up the daemon's own platform list, then look up whether the helper you intend to run has been touched since that release shipped. Where a project states support only up to a named release, treat the next one as untested until you have booted it.

Match the binary target to the userspace you have

Architecture is the quieter failure. A 64-bit kernel with a 32-bit userland is a real, supported combination on several boards, and it runs a 32-bit FTL binary without complaint, right up to the moment you install something that is only published for arm64. Print both halves before you choose an image, and keep the output next to your notes.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

If those two architecture lines disagree, you are on a mixed setup: workable for Pi-hole alone, fragile once a second service wants native libraries. Reflashing to a clean 64-bit image is usually faster than rebuilding the toolchain that produced the mismatch.

Board marketing does not settle this either. Memory size and CPU model say nothing about which libc your packages link against, so decide from the printed values, never from the product page.

One box, two services, one owner of the network

Decide who owns addressing, the resolver and the tunnel before the first package goes on, because otherwise two services end up claiming the same duty and neither wins cleanly. Give the Pi a static address outside the DHCP pool your router hands out, and keep the tunnel on its own subnet: 192.168.50.10 for the Pi and 10.42.0.0/24 for the tunnel is one workable split, and the numbers themselves are arbitrary as long as they do not collide with what your router already serves. Then write down which component answers on port 53, which one hands out DHCP if you use it, and which one owns the default route while the tunnel is up. On a headless image that last job belongs to NetworkManager or systemd-networkd, and installing a provider client that also rewrites the resolver configuration is how people end up with a live tunnel and dead DNS.

Sharing the box is fine. Sharing a role is not. Pi-hole wants to be the only listener on port 53, and the VPN daemon wants to push its own DNS setting to clients, so pick which of the two the clients should trust and configure the other to stay out of the way.

Keep the admin path off the tunnel where you can. If the resolver and the tunnel both fail together, you still want SSH reachable on the LAN address, and that means the management service must not depend on either.

Make the next upgrade part of the choice

A release you cannot upgrade is a support ceiling you have already accepted. Test the upgrade mechanics on a spare card before the appliance carries your household's DNS, and read what the projects say about jumping branches rather than assuming a package upgrade is enough.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

Held packages are the usual reason an upgrade looks successful and changes nothing. Clear the holds deliberately, one at a time, and note which service needed the pin.

Before the jump, export the Pi-hole configuration, the static leases and any tunnel profiles, and confirm you can restore them onto a fresh image. After the jump, test ordinary client DNS, the private resource behind the tunnel, a reconnect, and any forwarding rule on the gateway. A box that boots and answers ping has passed almost nothing.

When no single release fits both services

Sometimes the overlap is empty: the VPN helper has moved to a newer release than the Pi-hole package you can install, or the board's vendor image lags both. In that case separate the roles instead of editing release metadata to satisfy an installer. Two small devices, or one device plus a container for the second service, cost less than an appliance whose support story depends on a lie.

Faking the version is the one shortcut to refuse outright. Package managers trust what the release file says, so a spoofed identifier gets you an install that neither project will help you debug.

If two current releases do satisfy everything, pick the one whose upgrade notes you can follow without guessing, and stop shopping. Then record the version, the architecture, the service owners and the restore step in one place, because the next person to touch the SD card will need all four.