Open-source RADIUS server

Network logins and usage records
that survive a server failure.

radiusward authenticates Wi‑Fi, VPN and subscriber sessions against your users file, SQL database or Active Directory — and stores every session record on three servers before it answers, so a crash never loses a record or counts one twice.

Apache-2.0Docker · Kubernetes · systemd · Amazon ECSRelease candidate v0.1.0-rc.1

the quickstart, on a laptop
$ docker compose -f deploy/compose/compose.yaml up -d --wait
✔ node-0  node-1  node-2  gateway-a  gateway-b  postgres   healthy
$ deploy/compose/demo-failover.sh
load: 10,000 sessions, 2,000 requests/s for 25 s
kill -9 of the leader: node-2
new leader: node-0
verifying every acknowledged event against the replicated state...
sessions=10000
lost=0
What the quickstart prints: three cluster members and two gateways, the leader killed while 10,000 sessions report in, and every acknowledged record still there.
Built for

Networks where the session record matters.

Internet and wireless providers

Your invoice is built on session records. A RADIUS server outage, a lost Stop, or a retransmission counted twice turns into a billing dispute. radiusward keeps every record on three servers and counts each session once — through outages and failovers.

Campus and enterprise networks

Wi‑Fi and wired 802.1X, VPN: certificates or passwords against Active Directory, LDAP or SQL, a second factor if you want one. Logins keep working when a server is lost, and the records of who was online when are not.

Platform teams

One container image, a Helm chart tested every night under failures, Prometheus metrics with dashboards and alerts, a continuous backup — and no appliance. Runs on Kubernetes, plain hosts, or Amazon ECS.

The problem with RADIUS accounting

Session records (RADIUS accounting) are easy to lose and easy to double-count.

Lost in an outage

A device sends its session records to the RADIUS server and retries for a while. If the server is down for longer than that, the records — the usage you bill — are gone.

radiusward: a record is confirmed only after it is written to disk on two of three servers. A crash of any one of them loses nothing that was confirmed.

Counted twice on a retry

A device that gets no answer in time sends the same record again — often to its secondary server. A server that does not recognise the retry stores the session twice and inflates the usage.

radiusward: retries are recognised by session, not by server — also after a failover, also through the other gateway — and counted once.

Torn apart by a failover

With a primary and a secondary server, the Start lands on one and the Stop on the other. Reconciling them afterwards is where the ghost sessions and the billing errors come from.

radiusward: all gateways write to the same replicated state, so a session is one session wherever its records arrived. A failed leader is replaced in about two seconds.

Exactly what a confirmation guarantees →

Works with what you have

Your users, your devices, your database.

Your users
users fileSQLLDAPActive DirectoryActive Directory over Netlogon
Your devices
access points and switches (802.1X)VPN concentratorsbroadband gateways (BNG)captive portalsprivate LTE/5G Wi‑Fi offload
Methods
EAP‑TLSPEAPTTLSTEAPEAP‑pwdEAP‑SIM/AKAPAPCHAPMS‑CHAPTOTP
On the wire
UDPRadSec (TLS)DTLSTCPproxying to other RADIUS serversCoA and Disconnect
Your records go to
PostgreSQLJSON-lines filesanother RADIUS server
Runs on
DockerKubernetes (Helm)systemdAmazon ECS

All capabilities → Which method fits your clients →

See it survive

Tested against the failures that happen, every night.

radiusward is young: a release candidate, automated tests on every change, and published results — not yet a production track record, device certifications or an independent security audit.What the evidence shows, and what it does not →

Open source. Built in the open.

Apache-2.0. The code, every design decision, the tests and their results are public — and everything on this page can be reproduced on your laptop.

Search