The Pi-hole dashboard is a set of .lp templates, and its version field says 1.0.0

The manifest says 1.0.0 while the tags say v6.6

The package manifest is short and has three fields that are empty on purpose or by neglect:

  "name": "pi-hole-web-interface",
  "version": "1.0.0",
  "private": true,
  "description": "",
  "keywords": [],
  "author": "",
  "license": "EUPL-1.2",

It is marked private, it carries no description, no keywords and no author, and its version is 1.0.0. The repository, meanwhile, has tags v6.5, v6.5.1 and v6.6, the last published on 2026-07-06, and the most recent push to the master branch is dated 2026-10-03. So the version field is not tracking the release history at all, which is consistent with an interface that ships as part of Pi-hole releases rather than as a package anyone installs from a registry. Nothing in this repository depends on that number being accurate.

The same manifest points its homepage at the repository's own README rather than at the product site, and it files bug reports at the repository's issue tracker. For a reader deciding whether to fork it, the useful detail is that this is a component repository with no independent release cadence.

On licensing the three sources do not line up, and the honest answer is that they disagree. The repository metadata carries no recognized license, the manifest declares EUPL-1.2, and a LICENSE file exists at the root. Which text governs is not something this repository settles, so read the file before reusing any of it.

npm test runs prettier and xo, and nothing else

There is no unit test suite here, and the script named test does not pretend otherwise. It chains a formatting check and a lint check:

  "test": "npm run prettier:check && npm run xo:check",
  "testpr": "npm run prefix && npm run prettier:fix && git diff --ws-error-highlight=all --color=always --exit-code && npm run xo:check",

Prettier covers the stylesheets under style and the JavaScript under scripts, and xo does the linting with its own config file at the root. Everything the project calls a check is therefore about how the source looks, not about what the dashboard renders.

The other script is more revealing, because it documents how the CSS is built. The prefix step runs postcss over the main stylesheet and the theme stylesheets with autoprefixer, writing the result back in place with --replace and with source maps turned off. Then prettier rewrites the files, and then git diff runs with --exit-code. The build fails if regenerating the stylesheets produces anything different from what is committed. Compiled output is therefore part of the source tree and has to be updated in the same commit as the stylesheet that generated it.

Around those scripts the repository carries a `.codespellignore` for the spell checker, an `.editorconfig`, a `.devcontainer/` directory, `postcss.config.js` and `xo.config.js`, and a committed `package-lock.json`. The spell-check allowlist at the root is a small sign of how much text this project expects to accumulate outside the code.

Every dependency is pinned, and Bootstrap is still on 3.4.1

The dependency list has no version ranges at all. Every entry is an exact version, which means an upgrade is an edit to package.json rather than a resolution at install time, and the security exposure of the front end is exactly the set of versions printed here:

  "dependencies": {
    "admin-lte": "2.4.18",
    "bootstrap": "3.4.1",
    "chart.js": "4.5.1",
    "jquery": "3.7.1",
    "moment": "2.30.1",
    "select2": "4.0.13"
  },

The pairing worth noting is Bootstrap 3.4.1 with jQuery 3.7.1. The interface theme is AdminLTE 2.4.18, which sits on Bootstrap 3, while jQuery is at a much later major version than that theme was written for. Charts use Chart.js 4.5.1 with the moment adapter, deferred rendering and zoom plugins, tables use DataTables with Bootstrap, buttons and select extensions, and the date range control is daterangepicker 3.1.0. There is also a QR code generator, a tree view widget, a confirm dialog, a toast library, a progress bar, a spinner library and hammerjs for touch gestures.

Two consequences follow. The exact pins make a dependency review a matter of reading one file, which is unusually pleasant, and they also mean every bump is deliberate and has to be tested by hand, since nothing here runs a browser test. Meanwhile the front end remains on a UI generation that most current admin templates have moved past.

The front end is a flat directory of .lp templates

There is no application bundle to find in this repository. What there is, at the root, is a set of page templates with the .lp extension: `login.lp`, `index.lp`, `queries.lp`, `taillog.lp`, `search.lp`, `network.lp` and `interfaces.lp`. Group management is split across `groups.lp`, `groups-domains.lp`, `groups-lists.lp` and `groups-clients.lp`, and settings get one page per area: `settings-system.lp`, `settings-dns.lp`, `settings-dhcp.lp`, `settings-dnsrecords.lp`, `settings-privacy.lp`, `settings-api.lp`, `settings-teleporter.lp` and an all-in-one `settings-all.lp`. Error handling has `error403.lp` and `error404.lp`, and `gravity.lp` sits alongside them.

The rest of the tree supports those templates rather than compiling them. There is a `style/` directory with themes, an `img/` directory for the images each feature section shows, a `scripts/` directory for the JavaScript, and a `vendor/` directory. The only build step is the postcss pass over the stylesheets, so what you edit is what gets served, which makes a change easy to trace and easy to review.

One detail connects the pages to the dependency list: the settings tree includes a teleporter page and the packages include a QR code generator, so configuration export is implemented here rather than in the DNS component.

Three addresses to reach the dashboard, and no documented port

Installation is not a step. The interface is enabled by default when Pi-hole is installed, so there is nothing to install separately and nothing to start.

Access is where the detail sits, and there are three addresses:

https://<IP_ADDRESS_OF_YOUR_PI_HOLE>/admin/
https://pi.hole/admin/
https://pi.hole/

The second and third work when Pi-hole is being used as your DNS server, which is what makes the name resolve in the first place. None of the three names a port, so the interface is served from the same host as the DNS service rather than from a separate one, and the repository documents no port of its own. A tip note adds that the interface answers on either http or https.

Password protection is one of the listed features and `login.lp` is the page that implements it, but this repository does not say where the password comes from, what the default is, or how sessions are held. So the dashboard's own documentation covers where to point a browser and stops there, which is the right boundary for a component repository whose job is the interface.

Once you are logged in, the page is described as a place to see the domains queried on your network, the time queries were initiated, how many domains were blocked, which upstream server queries were sent to, and the type of each query, with A, AAAA, CNAME, SRV and TXT given as examples.

The query log and the tier marked Expert

The query log is the part of the interface with the most behaviour behind it. It shows recent and long-term data over user-defined time ranges, and it can be narrowed with an advanced filter. Above it sit the summary views: graphs and doughnut charts, and top lists of domains and clients. Blocking and allowing are managed through groups, where lists, individual domains set to block or allow, and regex entries are all handled, with the group management overview and a worked example both hosted on the Pi-hole documentation site rather than in this README.

The settings pages are organised in three groups, and each carries a subset of entries marked Expert in red. Under system settings those are DNS cache metrics, DHCP server metrics, and the Actions buttons. Under DNS settings they are interface settings, advanced DNS settings, DNS domain settings, rate-limiting and conditional forwarding, alongside upstream DNS servers including custom ones. Under DHCP settings they are the advanced settings, static configuration and the advanced description text.

That marker is a design decision rather than a permission system. The items stay visible in the interface and are labelled, so the distinction is meant to tell an operator which knobs change resolver or lease behaviour and should not be touched casually. Nothing in the repository enforces the distinction, which means an automation script that posts to the settings endpoint is not stopped by the label.

The README is a funding page and the licence fields disagree

Set against those pages, the README is mostly about keeping the project funded and about where to ask questions. It explains that there are recurring costs covered by volunteer developers, then lists payment routes: PayPal, a Coinbase checkout for Bitcoin, Bitcoin Cash, Ethereum and Litecoin, Patreon for patrons, and a set of affiliate links for DigitalOcean, Stickermule, Amazon and DNS Made Easy. Conference and meetup presenters are asked to get in touch for free swag.

The support boundaries are stated just as plainly. The project says to check the FAQ before opening a discussion and says outright that the volunteers do not have the spare time to reply to every request for assistance, and it lists the Discourse forum, Reddit, X, Facebook, Gitter and YouTube as the places it can be found. The technical documentation is not in the README at all: it lives at the documentation site, and the group management links point there too.

Two more things the README asserts about itself. The Pi-hole and FTLDNS names are registered marks with published brand guidelines, so the wording in the interface is not free for other projects to copy, and the web interface is credited as being based on AdminLTE. The repository is not archived, the last push to master is dated 2026-10-03, and the three licence signals, no license in the metadata, EUPL-1.2 in the manifest, and a LICENSE file at the root, still need reconciling before anyone reuses the code.

Editorial conclusion

pi-hole/web is worth reading if you want to change how a Pi-hole presents its query data, because the front end is deliberately shallow: page templates at the repository root, one stylesheet pipeline, no bundler, and a dependency list pinned to exact versions that you can read in one screen. It is not a place to look for a test suite, since the test script is prettier plus xo, nor for licensing clarity, because the repository metadata reports no license while the manifest declares EUPL-1.2 and a LICENSE file sits at the root. Before you change anything, confirm which license text governs, check that your Pi-hole version matches the tags you are branching from rather than the 1.0.0 in package.json, and remember that any CSS you edit has to be regenerated and committed, because the project's own pipeline fails the build when the regenerated output differs from what is in the tree.

Frequently asked questions

Official sources

1. Issues
2. pi-hole/web on GitHub
3. Project website
4. README
5. Releases