2026 Roadmap: SSO, Groups, and API Integration
4.0.6 and 3.9.9 now available
New year, new roadmap. Here’s what I’m working on and where things are headed.
Patch Releases: 4.0.6 and 3.9.9
Before diving into new features, a quick note on maintenance releases.
4.0.6 fixes zone deletion issues, IPv6 PTR record handling, disables MySQL SSL verification by default for backwards compatibility, and improves Docker healthchecks.
3.9.9 allows HTML characters in TXT records and fixes record name handling for those still on the 3.x LTS branch.
No database migrations needed for either - just update the files. If upgrading from 4.0.4 or earlier, run the 4.0.5 migration script first (sql/poweradmin-{mysql,pgsql,sqlite}-update-to-4.0.5.sql).
Q1: Wrapping Up 4.1 and Shipping 4.2
The first quarter is all about stabilization and one major new capability.
Version 4.1 (master branch) is in the final testing phase. This release has been a big one - over 50 issues closed. The highlights:
Federated authentication - you can now log in via OIDC and SAML. Azure AD, Keycloak, Okta, whatever your org uses. No more managing separate passwords for DNS admins.
Multi-factor authentication - TOTP-based MFA support.
Password reset - proper account recovery flow.
DNS record wizards - guided creation for DMARC, SPF, and DKIM records.
UI improvements - zone comment tooltips, better template navigation, pagination on search results.
Version 4.2 (develop branch) lands with group-based permissions. This has been requested for years (#480 on GitHub if you want the history). Instead of assigning zones to individual users, you’ll be able to assign them to groups and manage membership. Much more practical for larger teams. I’m also fixing the Azure AD group sync issue that some folks hit with OIDC.
Q2: The Big One - PowerDNS API Integration
This is where things get interesting.
For historical reasons, Poweradmin has always talked directly to the PowerDNS database. Back when the project started, that was the only option. PowerDNS didn’t have a REST API. But it does now, and has for years, and it’s time to use it.
Moving to the PowerDNS API as the primary interface is the focus for Q2.
Why does this matter? Because it unlocks a bunch of features that people keep asking for:
Remote PowerDNS servers - run Poweradmin on a different host than your DNS server. Proper separation.
LMDB backend support - LMDB isn’t SQL-based, so there’s no way to support it with direct database access. API mode makes it possible.
Multi-server management - manage multiple PowerDNS instances from a single Poweradmin. Internal servers, public-facing servers, whatever.
ExternalDNS integration - for the Kubernetes folks who want automatic DNS records from their ingresses.
Clean database separation - keep Poweradmin’s data completely separate from PowerDNS data. Different credentials, different hosts, whatever you need.
This is foundational work. Once the API layer is solid, a lot of other things become much easier to build.
What Comes After
If things go well with the API work, later in the year I’d like to tackle:
Granular API key permissions (restrict keys to specific zones or read-only access)
Domain metadata support (per-zone AXFR settings, TSIG keys)
Dashboard improvements with actual metrics visualization
But let’s see how Q1 and Q2 go first. No point making promises about Q4 in February.
If you’re using Poweradmin and have thoughts on priorities, the GitHub issues are always open.
The API migration is huge. Direct database access was fine when there weren't other options, but it creates so many constraints. Multi-server management alone will be a gamechanger for teams running split internal/external setups. The group-based permissions in 4.2 shouldve been there ages ago, glad to see it finally landing. Curious how the LMDB support performs once you get there.