Poweradmin: a PowerDNS control plane with a UI, a REST API, and a database dependency you have to choose

The gap Poweradmin fills between PowerDNS and the people who operate it

PowerDNS authoritative ships with a database schema and an HTTP API. Neither is a management interface. Editing a zone means writing rows into a domains and records table, or hand-crafting API calls, and neither path gives you a change log, role-based permissions, or a form that understands record types. Poweradmin is the layer that sits on top: a PHP application that presents zones, records, DNSSEC operations and a zone metadata editor for the PowerDNS domainmetadata table through a web UI, a REST API, or both at once. The README describes the intent plainly: use the UI for day-to-day operations, the API for scripts and infrastructure-as-code, or run completely headless after the initial setup, with the same validation running on every path. That last clause matters more than it reads. A tool that validates identically whether a change arrives from a browser form or a Terraform provider avoids the common split where the API accepts something the UI would have rejected. The audience is narrow and specific: teams already running PowerDNS authoritative who want self-hosted DNS administration without building their own panel. The topics list on the repository (dns, dnssec, pdns, self-hosted) reflects that positioning.

Two backends, and why the choice changes everything downstream

The README documents two operating modes. In the default SQL backend, Poweradmin works directly against the PowerDNS database, reading and writing zones and records at the table level, and uses the PowerDNS API only for DNSSEC operations. In API backend mode, described as native PowerDNS API backend mode, every operation goes through the PowerDNS HTTP API instead, and Poweradmin never needs direct database access. This is the single most consequential design decision in the project, and it is presented almost as a footnote. The SQL path is faster to set up if the database is reachable, and the README argues it is broadly compatible because the database schema stays relatively stable between PowerDNS releases. The API path removes the need to expose the database to a PHP application, which is the better security posture when the web tier and the DNS database sit in different trust zones. The cost is that every operation now depends on the PowerDNS API being up and correctly configured, and on the API exposing the feature you need. The README also notes that since 4.4.0 the interface detects the connected PowerDNS version and adjusts available features accordingly, so record types, metadata kinds and terminology follow the server you connected to. That is a real engineering commitment: it means the codebase carries version-conditional behaviour rather than assuming one PowerDNS generation.

What the interface actually exposes: DNSSEC, metadata, bulk operations and a change log

Beyond basic zone and record editing, the feature list names several things that are awkward to do by hand. All zone types are covered: master, native and slave, plus supermasters and zone templates. DNSSEC operations are included, which is why the SQL backend still reaches for the PowerDNS API even when it otherwise works at the database level. The zone metadata editor targets PowerDNS domainmetadata, and the README is specific about how it handles multi-value metadata such as ALLOW-AXFR-FROM, using one row per value, with known metadata kinds offered alongside inline guidance and custom kinds accepted when needed. Bulk operations exist for records and for reverse DNS, and secondary zones can be imported over AXFR. There is a record change log with before and after snapshots of every record and zone change, which is the feature that most distinguishes this from scripting the PowerDNS API directly. Access control is handled through users, groups and role-based permissions, with LDAP, SAML, OIDC and TOTP two-factor authentication listed. The REST API is documented with OpenAPI, and API keys can be read-only, restricted to specific operations, or scoped to specific zones. That scoping granularity is what makes the Terraform, ExternalDNS, cert-manager and Certbot integrations practical rather than a shared root credential.

Getting it running: Docker environment variables and the release-branch warning

The README's quick start is a single command: docker run -d --name poweradmin -p 8080:80 -e DB_TYPE=sqlite -e PA_CREATE_ADMIN=1 poweradmin/poweradmin:latest. Two environment variables carry the important behaviour. DB_TYPE is required and accepts sqlite, mysql or pgsql. PA_CREATE_ADMIN is what creates an admin user, because the README states that no admin user is created by default for security reasons, and that the generated secure password is shown in the logs. For an API-first deployment, the README says to add -e PA_API_ENABLED=true -e PA_API_DOCS_ENABLED=true and follow the headless quickstart, which it claims takes you from zero to scripted record updates in about five minutes. Images are published on Docker Hub as poweradmin/poweradmin and on GitHub Container Registry as ghcr.io/poweradmin/poweradmin, with Docker secrets documented separately. The non-Docker route is to take a stable release archive, or to clone from Git, and here the README carries an explicit warning worth repeating: the master branch is used for development of the next major release and may be unstable, so production users should stick with the release/4.3.x branch, a specific version tag such as v4.3.4, or the stable Docker tag. Requirements are PHP 8.2 or higher with intl, gettext, openssl, filter, tokenizer, pdo, xml and one of pdo-mysql, pdo-pgsql or pdo-sqlite, plus ldap if you want it, a MySQL 5.7.x/8.x, MariaDB, PostgreSQL or SQLite database, and PowerDNS authoritative 4.0.0 or later including the 4.x and 5.x series.

The version matrix is the part that will bite you

Poweradmin maintains several release branches simultaneously, and the README's own table makes the maintenance burden visible. The 4.4.x line is current, 4.3.x is stable, 4.2.x is in maintenance, and 3.x is the LTS branch. Officially tested combinations are listed per branch: 4.4.x and 4.3.x were tested on PHP 8.2, PowerDNS 4.9.12, MariaDB 10.11 and PostgreSQL 16.11, while the 3.x LTS line was tested on PHP 8.1, PowerDNS 4.7.4, MariaDB 10.11, MySQL 9.1, PostgreSQL 16.3 and SQLite 3.45. Note the PHP floor difference: the 3.x LTS branch runs on PHP 8.1, but the current branches require 8.2. If your distribution packages PHP 8.1, that single fact decides which branch you can deploy. PowerDNS 4.8.x, 4.9.x and 5.0.x are described as user-reported compatibility rather than officially tested, which is a meaningful distinction: community reports are not the same as a tested matrix entry. Three releases landed on the same day in this snapshot, v4.4.1, v4.3.5 and v4.2.6, all dated 2026-09-04, which suggests security or correctness fixes are backported across the supported lines rather than only landing on the newest branch. That is a good sign for the LTS path, but it also means you should track which branch your deployment follows, because upgrading across branches is not the same operation as upgrading within one.

Where Poweradmin is the wrong tool

Poweradmin is not a DNS server and does not replace PowerDNS. It is an administration layer, and the README is explicit that PowerDNS authoritative 4.0.0+ must already be running. If you have no PowerDNS deployment, this project does nothing for you. A second limitation follows from the backend split: in SQL backend mode Poweradmin needs database credentials for the PowerDNS database, which means the PHP application holds write access to the same tables the nameserver reads. In API backend mode it needs a PowerDNS API endpoint instead, and every operation inherits the availability of that API. There is no third option where Poweradmin manages zones without either. The README does not describe a degraded mode, a read-only fallback, or an offline queue, so an unreachable backend is an unreachable interface. A third constraint is the PHP runtime itself. Requiring PHP 8.2+ with intl, gettext, tokenizer and xml is not exotic, but it is a real dependency chain to keep patched, and the FrankenPHP-based Docker image is the path the README leads with. Teams that have standardised on running DNS infrastructure without a PHP runtime in the stack will find that this tool adds one. Finally, the README gives no information about performance under large zone counts, no guidance on horizontal scaling, and no statement about what happens to in-flight changes if the database connection drops mid-operation. Those are open questions rather than documented limitations, and they should be treated as unverified.

Alternatives: scripting the PowerDNS API directly, or a different management model

The most direct alternative is to skip Poweradmin and call the PowerDNS HTTP API from your own scripts and CI pipelines. PowerDNS already exposes an API, and the README itself points out that Poweradmin's REST layer is what the Terraform provider, the ExternalDNS webhook, the cert-manager webhook and the Certbot plugin wrap. If your workflow is entirely automated and no human ever opens a browser to edit a record, the value Poweradmin adds is the validation layer, the change log with before and after snapshots, the role-based permissions and the scoped API keys. If you do not need those, you are maintaining a PHP application and a database schema for an interface nobody uses. The honest comparison is not Poweradmin versus another DNS panel. It is Poweradmin versus your own thin client over the PowerDNS API. The trade is explicit: you give up the UI, the permissions model and the audit trail, and in return you remove a runtime, a web tier and a set of credentials. For a small number of zones managed by one team, that trade often wins. For multiple teams sharing a PowerDNS installation where someone needs to see who changed a record and when, the change log and the group permissions are the features that justify the deployment. The version-aware interface is a secondary argument: if you track PowerDNS releases, Poweradmin adjusts record types and metadata kinds to the connected server, which is work you would otherwise redo in your own client.

Licence, upgrade cost and the release-branch discipline it demands

Poweradmin is GPL-3.0. If you deploy it as a separate service alongside PowerDNS, that is the ordinary case the licence anticipates. If you modify the PHP source and distribute the result, or embed it in a product you ship, GPL-3.0 obligations attach to the distributed work, and the specifics depend on your situation. That is a question for your own counsel, not something to settle from a README badge. On upgrade cost, the material supports one concrete observation: the project runs four release branches at once, with the 3.x LTS line on PHP 8.1 and the current lines on PHP 8.2+, and the README tells production users to avoid master in favour of release/4.3.x, a version tag such as v4.3.4, or the stable Docker tag. The practical consequence is that you must pin something. Following the latest tag means following the newest branch, which is the one whose tested matrix is narrowest relative to how recently it changed. Following the LTS branch means accepting an older PowerDNS and PHP baseline. Either way, the upgrade path is a branch decision made once at deployment, not a per-release decision made later. The Docker image tag you choose is the same decision expressed differently, and the README's own recommendation of the stable tag over latest is the clearest guidance it gives.

Editorial conclusion

Adopt Poweradmin if you already run PowerDNS authoritative and want a browser UI plus a scriptable REST API over the same validation path, and you are willing to run PHP 8.2+ with intl, gettext, openssl, filter, tokenizer, pdo and xml. Do not adopt it if you need a DNS server bundled with its own management layer, or if you cannot give it either database access or a PowerDNS API endpoint. Before rolling it out, verify which backend mode you intend to run, confirm your PowerDNS version against the tested list, and check whether the release branch you are about to deploy is 4.4.x, 4.3.x or the 3.x LTS line, because the README states that master tracks the next major release and may be unstable.

Official sources

1. License: GPL-3.0
2. poweradmin/poweradmin on GitHub
3. Project website
4. README
5. Releases