Web UI for ISC Kea DHCP

Stop editing Kea JSON by hand.

Install it next to Kea. It finds your config.

EZ-KEA is a self-hosted web interface for ISC Kea. Manage DHCPv4 and DHCPv6 subnets, pools, reservations, prefix delegation, DHCP options and high availability (and search your full Kea log history) against the config file your daemons already read. No migration, no hosted control plane, no second copy of the truth.

Try the live demo Get started View on GitHub

Dual stack, with prefix delegation
Nothing calls home
Free for noncommercial use
$500/year commercial, per deployment

The EZ-Kea home screen: a navigation bar carrying DHCPv4, DHCPv6, IPv4 and IPv6 reservations, IPv4 and IPv6 leases, HA, settings and logs; a row of backup, restore, test-syntax and apply-changes actions; and cards linking to each pools, reservations and leases view

How it fits

Keep the Kea deployment you already have.

EZ-KEA is not a DHCP server and does not want to become your addressing platform. It installs beside the Kea you are already running, reads the configuration that Kea is actually using, and hands you a real interface for changing it.

01
Your Kea keeps running

Same packages, same service, same config file. Nothing is exported, imported, or migrated.
02
EZ-KEA discovers it

It reads the config path off the running kea-dhcp4 and kea-dhcp6 daemons. There are no paths to enter to get started.
03
You manage it in the UI

Subnets, pools, reservations, prefix delegation, options and the HA hook, as forms, not as nested JSON.
04
Changes are validated

Every write is backed up first, and the config is syntax-checked with Kea's own binary before it is applied.
05
Kea reloads

Via keactrl, the daemon's control socket, or a SIGHUP for Docker-based installs. You pick which.

EZ-KEA manages Kea. It does not replace Kea. If you uninstall EZ-KEA tomorrow, what is left behind is an ordinary Kea configuration file that your daemons keep serving from.

It edits your real config, in place.

No parallel database, no exported-then-imported copy of the truth, no new source of drift between what the UI shows and what your DHCP server is actually serving.

One config, not two.

EZ-KEA writes to the same file your Kea daemons already read. There's no sync step to forget and nothing to reconcile after someone edits the JSON by hand. What you see in the tables is what's on disk.

Every write is backed up first.

Not a button you have to remember: EZ-KEA copies the config before it modifies it, and refuses the write outright if that backup fails. Syntax-check before you apply, restore from the UI if you need to. A bad edit is a restore away, not an outage.

Runs where your DHCP runs.

Binds to loopback by default, and refuses to start at all on a routable address while the secret key is still the shipped default. Exposing it to the network is a decision you make deliberately, not one you can make by forgetting.

Capabilities

The work you actually do, without the JSON.

Every feature below exists because a config file made something harder than it needed to be.

Who had this address, and when

An abuse report, a support ticket, or an incident review names one address and one timestamp, usually weeks back and several rotations deep, in a file that has since been gzipped. EZ-KEA indexes your whole retained Kea log history, archives included, and searches it by MAC, IP, whole subnet, time range, severity, and v4 or v6. MACs match in any spelling, and inside a client-id or DUID. Results export to CSV, and every search is a linkable URL you can paste into the ticket.

Subnets and pools, as forms

Stop hunting through nested objects to add a subnet or move a pool boundary. Shared networks, standalone subnets and address pools for both families, with a new subnet checked against every subnet you already have (including the ones inside shared networks) and a pool range that falls outside its subnet or runs backwards rejected in the form rather than by the daemon.

IPv6 that isn't an afterthought

DHCPv6 is a first-class view, not a tab bolted onto v4. Subnets, address pools, per-subnet options and prefix delegation: a pd-pool with its delegated length, validated against the pool's own prefix, so a router or CPE downstream of you gets a block to hand out rather than a single address.

Reservations without a config edit

Pin a customer's CPE, a printer, or a piece of lab kit to an address without opening a file. MAC-based for DHCPv4, DUID-based for DHCPv6, covering fixed addresses, delegated prefixes, or both on the same reservation.

The HA hook, without the hand-editing

Kea's libdhcp_ha.so block is easy to get subtly wrong and expensive to get wrong in production. EZ-KEA writes it for you (hot-standby, load-balancing or passive-backup, with the peer list, roles and timers as fields) and checks the peer set is coherent before saving. A heartbeat button reads current peer state back off the daemon's control socket.

DHCP options you don't have to look up

Fifteen common options are one pick away, each with an example and a hint: gateway, DNS, domain, NTP, syslog, IP forwarding, TFTP server and bootfile for PXE netboot, and the TR-069 ACS URL for provisioning CPE. Anything else Kea accepts, you set by name. Options are editable in place, per subnet or globally.

Kea 2.x and Kea 3.x

Kea 3.0 renamed the control socket block and 3.2 removed the Control Agent, so a config that was valid last year can be rejected today. EZ-KEA checks the version of the daemon it found and writes the syntax that version accepts. Applying changes works on 3.2 too, where ISC's own packages ship no keactrl at all.

Service providers

Built for networks where DHCP actually matters.

The features that separate a homelab DHCP tool from an operational one are the boring ones: v6 that works, prefix delegation, a redundancy story, and being able to answer "who had this address on the 14th" three weeks later. EZ-KEA covers those.

Prefix delegation for CPE. pd-pools with delegated lengths, so subscriber routers get a block, not an address.
Full DHCPv6 management. Subnets, pools, options and DUID reservations, in the same interface as v4.
Historical log search. Answer abuse and law-enforcement requests from indexed history rather than by grepping gzipped archives by hand.
CSV export and linkable searches. Attach the evidence to the ticket instead of pasting a terminal scrollback.
HA hook configuration. Hot-standby, load-balancing and passive-backup written correctly, with peer state readable from the UI.
Per-subnet options that matter to CPE. TFTP server and bootfile for netboot, and the TR-069 ACS URL for provisioning.
Validation before apply. A syntax error is caught by Kea's own binary before your subscribers find it.
Automatic pre-write backups. Every config change is copied first, pruned to the most recent hundred.
Runs entirely on your own hardware. No SaaS control plane, no agent fleet, no external database server.
Works with no internet egress. Suitable for an isolated management VLAN; license keys verify offline.

Multi-user from the start, with optional TOTP two-factor, recovery codes, and SMTP-backed password reset. Secret keys, file permissions and reverse-proxy TLS are covered in the Security Hardening guide rather than left as an exercise. Note that EZ-KEA's accounts are administrator or standard: there is no read-only role, so anyone you give an account can change DHCP configuration.

Screenshots

See it before you install it.

The real application, running against a fully synthetic data set.

Kea DHCP log search: a MAC address typed into the search box, recognised as a MAC, returning 48 matching log lines spanning several days of lease allocations, renewals and releases, with a CSV export button — Find who held an address, weeks back and several log rotations deep. Search by MAC, IP, subnet or text; export the answer as CSV.

Kea DHCPv4 pool management, showing shared networks containing subnets, each with its router option and address pool range — Your DHCPv4 shared networks, subnets and pool ranges as a table instead of nested JSON.

The add-new-IPv4-subnet form, with fields for the shared network group, subnet CIDR, default gateway, a static-assignments-only toggle, and the pool start and end addresses — Add a subnet without opening a config file. Overlaps and out-of-range pools are rejected here, not by the daemon.

The Kea DHCPv6 pools view, showing IPv6 subnets, address pools, and a prefix-delegation pool with its delegated length — IPv6 prefix delegation in the same interface as everything else: a pd-pool and its delegated length, not a separate tool.

The Kea high availability page, showing hot-standby mode, heartbeat and response timers, the libdhcp_ha.so hook library path, and a peer table with a primary and a standby server — Kea's HA hook as fields rather than a hand-written block, with a heartbeat check against the live daemon.

The MAC reservations view, listing DHCPv4 host reservations by hardware address, IP address and hostname — Pin a device or a customer's CPE to an address, by MAC for v4 or DUID for v6.

The DHCPv4 lease table, showing active leases with addresses, MACs, hostnames, and expiry times — What's live right now, read straight from Kea's own lease file.

Architecture

One Python process, next to your daemons.

EZ-KEA is a self-hosted web application you run on the same host as Kea. It has no agents, no external database server, and no hosted control plane to depend on.

Discovery

EZ-KEA determines the configuration your running Kea process is actually using, so you don't have to tell the UI where your config lives, and so it can't drift onto a stale copy. Every path it infers is overridable in Settings when your layout is non-standard. (Mechanically: it reads the running kea-dhcp4 and kea-dhcp6 processes from /proc and takes the path each daemon was launched with, falling back to the standard locations under /etc/kea.)

In-place editing

Changes are written to Kea's own JSON file. There is no import step, no export step, and no second store that can disagree with what the server is serving. Concurrent edits are serialized per config file.

Backup, validate, apply

Every write copies the existing config first and aborts if the copy fails, keeping the hundred most recent. Applying runs Kea's own binary in syntax-check mode and stops on failure, then reloads via keactrl, the control socket, or SIGHUP, whichever your install actually supports.

Storage

Two embedded SQLite files: one for local accounts and settings, one a disposable index over your Kea logs that rebuilds itself if you delete it. No Postgres, no MySQL, no message broker, nothing else to operate.

No egress

EZ-KEA makes no outbound network calls: no telemetry, no CDN, no update check, no license server. Fonts and icons are vendored and license keys verify offline against a key compiled into the application, so it runs on an isolated management VLAN.

Tested against real Kea

Alongside the unit suite, EZ-KEA has a containerized testbed that boots an actual Kea server on simulated VLANs and drives real DHCP transactions through it, against both Kea 2.0.2 and Kea 3.2.0, which is how the 3.x packaging differences were found rather than assumed.

If you manage a fleet of Kea and BIND servers and want central monitoring, pool utilization graphs and Grafana integration, ISC Stork is a good tool and solves a different problem. EZ-KEA is for the case where you already run Kea, you are happy with how it's deployed, and you just want to stop editing its configuration by hand.

Pricing and licensing

Free for your homelab, licensed for business.

Noncommercial use is free, with no limits of any kind. Commercial use requires a commercial license: $500 a year per production deployment. Running more than one? Contact us for volume pricing. EZ-KEA is source available under the PolyForm Noncommercial 1.0.0 license: read the source, run it, change it.

Personal and noncommercial use

Free

Use EZ-KEA freely for personal projects, homelabs, education, and other noncommercial purposes. Nothing to buy and nothing to register.

Install it

Commercial license

$500/year

For commercial use in production environments. Includes the full EZ-KEA feature set and licensing for a single deployment.

Want to try it at work first? Free 30-day evaluation: ask for a trial key.

Buy a commercial license

Volume licensing

Custom pricing

Need EZ-KEA across multiple deployments, sites, customers, or environments? Contact us for volume licensing.

Ask about volume licensing

A single deployment is one production EZ-KEA installation, in one environment, operated by one organization. Running more than one? That's volume licensing: tell us how many and we'll quote it.

01 Free for noncommercial use. Every feature, no lease ceiling, no feature gates, no time limit, not a trial. Homelabs, personal networks, hobby projects, learning and experimentation, plus charities, schools, public research bodies, and government institutions.
02 Commercial use requires a commercial license. $500 per year, per production deployment. Keys are RSA-2048 signed and verify offline; nothing phones home. The full definition is in the terms; if you're unsure whether your use counts, just ask.
03 Try it at work for 30 days, free. A full commercial evaluation key, no questions asked and no card needed. Email sales@ezkea.com and we'll send one. It's the same build you'd buy; the eval just decides whether you buy it.
04 More than one deployment is volume licensing. ISPs, MSPs, enterprises, and multi-site operators are priced on how many production deployments they run rather than off a list price. Write to sales@ezkea.com with the number and we'll quote it.
05 Nothing is ever blocked. An unlicensed install shows a quiet note in the footer, and past 100 active leases it adds an informational reminder. That is the entire mechanism: no write lock, no grace period, no expiry.

Your DHCP server never becomes hostage to the license. Nothing is blocked, degraded, or expired if a key lapses; an unlicensed install shows a note, and keeps working. It's your addressing; EZ-KEA will not lock you out of it.

Buy a commercial license Read the licensing details

Need an invoice or a purchase order instead of paying by card? Write to sales@ezkea.com: that works for a single deployment too, and it's the right address for volume licensing or to check whether your use counts as commercial.

Quick start

Running in five commands.

Requires Python 3.10 or newer, on the same host as your Kea daemons. Kea 2.x and 3.x both work: the testbed exercises 2.0.2 and 3.2.0. Kea itself stays where it is, running as its own service, and is optional to get started: without it, EZ-KEA runs in demo mode against a local sandbox so you can try the interface first.

# On Debian/Ubuntu, python3-venv ships separately from Python.
$ sudo apt install python3-venv

$ git clone https://github.com/fenleytech/ez-kea.git
$ cd ez-kea
$ python3 -m venv venv && source venv/bin/activate
$ pip install -r requirements.txt
$ python3 app.py

# Open http://127.0.0.1:8080 and sign in with admin / changeme.
# You'll be required to change both on first login.

If Kea came from your distro or ISC's packages, its config is owned by Kea's own account: add the account EZ-KEA runs as to that group (sudo usermod -aG _kea $USER) and make the configs group-writable, or EZ-KEA can't read or reload them. Kea 3.2 also ships no keactrl, so pick Control socket as the reload strategy in Settings. Both are covered in the Installation guide.

Running it as a systemd service, pointing it at a non-standard Kea layout, and Docker-based Kea deployments are all covered in the Installation guide.

Ready to see it against your own config?

The demo is a shared sandbox on entirely synthetic data, and it resets every 30 minutes, so create and delete whatever you like. Log in with demo / demo.

Get started Open the live demo View on GitHub Commercial licensing