Poweradmin: a self-hosted web UI and REST API for PowerDNS

What Poweradmin adds to a PowerDNS server

PowerDNS itself is a nameserver. Editing zones means either writing SQL against its database or calling its HTTP API by hand. Poweradmin is the missing operator layer: a PHP application that manages zones, records, supermasters, zone templates, DNSSEC operations and the PowerDNS domainmetadata table through a web interface, a REST API, or both at once. The README describes it as a DNS administration tool that can be driven through a friendly web UI, a REST API, or both at the same time, with the same validation running on every path.

The audience is narrow and specific. You need to be running PowerDNS authoritative server 4.0.0 or later. If you are on BIND, Knot or a managed DNS provider, Poweradmin has nothing to manage. If you are on PowerDNS and your current workflow is a phpMyAdmin tab and a text file of SQL statements, this is the tool the project is aimed at. The feature list also covers the parts of PowerDNS that are awkward to touch by hand: all zone types including master, native and slave, supermasters, zone templates, bulk record operations, reverse DNS, secondary zone import over AXFR, and a record change log that keeps before and after snapshots of every record and zone change.

Two backends: direct database access or the PowerDNS API

The architectural choice that matters most is how Poweradmin talks to PowerDNS. In the default SQL backend, it operates primarily at the database level, reading and writing the PowerDNS schema directly, and uses the PowerDNS API only for DNSSEC operations. The README notes that the database schema stays relatively stable between PowerDNS releases, which is why compatibility is broad across 4.x and 5.x.

The alternative is API backend mode, where every operation goes through the PowerDNS HTTP API and Poweradmin never needs direct database access. That is the mode to pick when the database is not reachable from the web host, or when you want PowerDNS to remain the single writer. The trade-off is real: in SQL mode you get a wider set of features and fewer moving parts on the PowerDNS side, but you are coupling the application to a schema that PowerDNS owns. In API mode you gain isolation and lose the directness.

Since 4.4.0 the interface also detects the connected PowerDNS version and adjusts record types, metadata kinds and terminology to match. That is a quiet but useful piece of engineering, because PowerDNS has changed available record types and metadata kinds across releases. On top of that sits a zone metadata editor for PowerDNS domainmetadata, with known metadata kinds offered with inline guidance, the option to enter custom kinds, and multi-value metadata such as ALLOW-AXFR-FROM entered one row per value.

Installing Poweradmin with Docker and creating the first admin

The README points to the official documentation for detailed installation, and offers two paths. The recommended one is to take the latest stable release from the GitHub releases page. The Git path comes with an explicit warning: the master branch is used for development of the next major release and may be unstable, so production users are told to stay on the release/4.3.x branch, a specific version tag such as v4.3.4, or the stable Docker tag.

For a quick local look, the README gives this command. It starts the container on port 8080, selects SQLite as the database, and asks for an admin user to be created.

docker run -d --name poweradmin -p 8080:80 -e DB_TYPE=sqlite -e PA_CREATE_ADMIN=1 poweradmin/poweradmin:latest

Two details from the README matter here. DB_TYPE is required and accepts sqlite, mysql or pgsql. And no admin user is created by default for security reasons; PA_CREATE_ADMIN=1 triggers creation, with a secure password generated automatically and shown in the container logs. The default username is admin, overridable with PA_ADMIN_USERNAME, and you can set your own password with PA_ADMIN_PASSWORD. Read the logs before you close the terminal.

If the goal is scripted record changes rather than a browser session, the README adds two environment variables and points to a headless quickstart that it says takes zero to scripted record updates in about five minutes.

docker run -d --name poweradmin -p 8080:80 \
  -e DB_TYPE=sqlite \
  -e PA_CREATE_ADMIN=1 \
  -e PA_API_ENABLED=true \
  -e PA_API_DOCS_ENABLED=true \
  poweradmin/poweradmin:latest

Images are published on Docker Hub as poweradmin/poweradmin and on the GitHub Container Registry as ghcr.io/poweradmin/poweradmin. The container is built on FrankenPHP. Note that the Dockerfile in the repository is labeled as intended only for TESTING, so treat it as a development aid rather than the production recipe. For secrets, the entrypoint supports environment variables with a __FILE suffix, for example DB_PASS__FILE pointing at a mounted file. A traditional install needs PHP 8.2 or higher with the intl, gettext, openssl, filter, tokenizer, pdo, xml and a pdo driver extension, plus ldap if you want it.

Where Poweradmin is the wrong tool

The first limitation is structural: Poweradmin is a management interface, not a nameserver. It cannot serve DNS. If you want one binary that answers queries and offers an admin panel, this is not it, and the project does not pretend otherwise.

The second is the coupling in the default mode. Working at the database level means the Poweradmin host needs credentials that can write to the PowerDNS schema. Anyone who reaches the Poweradmin application, or its configuration, effectively holds those credentials. API backend mode avoids that, but the README does not describe a migration path between the two modes, so choosing one at install time is a decision worth getting right. If your PowerDNS database is only reachable from the nameserver host, the default mode may simply be unavailable to you.

The third is version drift. The README lists officially tested combinations, and PowerDNS 4.8.x, 4.9.x and 5.0.x are described as user-reported rather than officially tested. The compatibility argument rests on the database schema being stable between PowerDNS releases, which is a reasonable bet but not a guarantee. If you run a PowerDNS version outside the tested list, you are relying on that stability argument.

Finally, the project maintains several release branches at once, and the README itself warns that master may be unstable. Running from Git master in production is a mistake the documentation explicitly tells you to avoid.

Poweradmin compared with PowerDNS Admin

The obvious alternative is PowerDNS Admin, the other long-standing web front end for PowerDNS. Both are PHP applications that manage zones and records in a PowerDNS database, and both exist because PowerDNS ships no admin UI of its own. The difference in approach is in what surrounds the core editing screen.

Poweradmin's distinguishing bet is automation. Its REST API is documented with OpenAPI, and the project maintains ready-made integrations that wrap it: terraform-provider-poweradmin for Terraform and OpenTofu, external-dns-poweradmin-webhook for Kubernetes ExternalDNS, cert-manager-webadmin for DNS-01 challenges, and certbot-dns-poweradmin for Let's Encrypt. That means a zone can be created by Terraform and a certificate issued through the same API without a browser. API keys can be made read-only, restricted to specific operations, or scoped to specific zones, which is what makes handing a key to a CI job defensible.

The second difference is the API backend mode. Where a database-backed admin panel requires direct SQL access, Poweradmin can run entirely through the PowerDNS HTTP API. If your PowerDNS deployment does not expose its database, that single capability decides the comparison. If you are happy with a database-backed panel and do not need infrastructure-as-code, the two tools overlap heavily and the choice comes down to which UI your team prefers. Poweradmin also carries users, groups and role-based permissions with LDAP, SAML, OIDC and TOTP two-factor authentication, and 43 languages including right-to-left, so it can serve as the access-control boundary for a team rather than a single admin password.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-08. The most recent releases are v4.4.1, v4.3.5 and v4.2.6, all dated 2026-09-04, which shows the project shipping maintenance releases across three branches on the same day. The README describes release/4.4.x as current, release/4.3.x as stable, release/4.2.x as maintenance and release/3.x as LTS. That branch structure is the upgrade cost in practice: you pick a line, and moving between lines is a deliberate step rather than an automatic one.

Licensing is GPL-3.0. The Dockerfile labels the image as GPL-3.0-or-later. For most operators running Poweradmin as an internal tool this is unremarkable, but if you intend to redistribute a modified version, or to embed it in a product, the copyleft terms apply and are worth reading in full. This is not legal advice; consult someone qualified if the distribution model is unclear.

Operationally, the maintenance surface is a PHP application plus a database plus the PowerDNS server it manages. There is no separate agent to deploy. The upgrade path the README endorses is release tarballs or tagged images, not Git master, and the stable Docker tag exists precisely so that a pull does not silently move you onto an unreleased branch.

Editorial conclusion

Adopt Poweradmin if you already run PowerDNS and want one place for browser edits, DNSSEC operations, role-based users, and a REST API that Terraform, ExternalDNS, cert-manager and Certbot integrations already wrap. Do not adopt it if you do not run PowerDNS, since it manages that server rather than replacing it. Before rolling it out, confirm your PowerDNS version against the compatibility note, decide between the default SQL backend and API backend mode, and check what your PowerDNS database user is allowed to do, because in the default mode Poweradmin works at the database level.

Frequently asked questions

Official sources

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