A complete, modern, containerized RADIUS authentication stack designed for ease of deployment, security, and extensive API-driven management. RadiusStack bundles FreeRADIUS, MariaDB, and a custom Node.js REST API inside a streamlined Docker Compose environment, paired with a sleek, responsive Web UI.
Useful for managing Wi-Fi access points, remote access, or network appliance logins, RadiusStack provides full control over users, usage plans, profile attributes, and feature riich monitoring and analytics. Designed for security and simplicity.
Try the demo:
https://demo.radius-stack.com
admin account: admin / demo123
Reports account: reports / demo123
- Modern Web Interface: WebUI frontend for managing NAS clients, users, profiles, plans etc. Also view logs for all containers within the webui.
- Full REST API: The managment application is an API server. The Webui only interacts with the API and therefore doesn't have access to the backend database.
- Advanced Security: Supports Time-Based One-Time Passwords (TOTP) for radius users and Webui administrators
- Intelligent Backups: Export and safely restore JSON-based database configurations across version upgrades.
- Automated Certificate Generation: One-click custom SSL/EAP certificate generation or direct file uploads.
- Live Analytics: Monitor active sessions, view authentication/accounting logs, and detailed administration audit log.
- High Availability: Full config, object and session sync between members. See the wiki for more details.
HA sync uses the configured peer's API (HA_PEER_IP) with AES-256-GCM encrypted payloads. A public IPv4 peer is accepted, but the existing HA transport is plain HTTP, not end-to-end TLS, and the published API port may expose unrelated endpoints. Prefer a private tunnel/VPN and firewall the API to the peer; do not expose database, phpMyAdmin, or the general API broadly. Source-address pinning checks the actual socket address, not X-Forwarded-For, so NAT/proxy paths need verification. Leave HA_ENABLED=false until both nodes and the shared HA_API_TOKEN are configured and tested. HA_DB_OFFSET and auto_increment_increment=2 partition some new auto-generated IDs; they do not reconcile existing data. Do not bootstrap HA by enabling both populated nodes and pressing Full Sync: the current endpoint queues unbounded upserts, does not delete stale secondary rows, and acknowledges some duplicate conflicts without resolving them. Back up both databases, designate one authoritative primary, prepare a clean/verified secondary copy, isolate secondary writers, check schema/offsets/queue and row counts, then rehearse sync and failover on disposable clones before production use.
Extract the versioned source asset on the new machine. It contains a grouped .env with working public defaults and needs no first-run script. From that directory run docker compose up -d --build (provided its published ports are free). Review RADSEC_SERVER_DNS before using RadSec. Change the shared default passwords and encryption key before exposing a production installation, and keep the customized .env private and unchanged during upgrades. The deployable source folder includes the public-default .env but not .env.example; customize .env before exposing the new installation, and never copy the primary machine's private .env into public source.
Version 5.5.6 fixes HA full sync and replay for the admins.permissions JSON field, including admin rows already queued by an older primary. Keep the HA queue intact; upgrade the secondary first and verify delivery after both peers are updated. It also adds a nonblocking GitHub release check below the sidebar version, with a one-hour browser cache and an honest fallback when GitHub is unavailable. There is no new SQL migration. Use the 5.5.6 upgrade guide only after its matching GitHub Release asset and digest are published; publishing is a separate manual step.
Version 5.5.5 hides the tenant-specific depleted-allocations widget in Global context (and skips its requests), while retaining it within selected tenants. The Global RADIUS Container Health widget now shows healthy when all five RadiusStack containers are running and Degraded if any is stopped or missing, rather than interpreting the absence of optional Docker healthchecks as unknown. This is a running-state indicator, not an application-level health probe. It retains the 5.5.4 updater and HA peer improvements; there is no new SQL migration. Use the 5.5.5 upgrade guide only after its matching GitHub Release asset and SHA-256 digest are published. Installed 5.5.2 needs the verified bootstrap; 5.5.3 and 5.5.4 can use their installed updater.
Version 5.5.4 accepts a configured usable public IPv4 HA peer (as well as a private IPv4 peer) while rejecting loopback, link-local, multicast and malformed addresses. The updater runs a private copy of itself, preventing Bash from reading replacement bytes when upgrade.sh is updated. Its restricted debug log retains all file, migration and Docker details; the terminal shows concise progress or failure milestones and the log location instead of dumping the transcript. HA remains plain HTTP: protect the transport with a private tunnel/VPN and firewall; this fix does not make direct Internet API exposure safe. No new database migration is added. 5.5.2 installations must run the digest-verified 5.5.4 bootstrap in the upgrade guide, not their installed updater; 5.5.3 installations can run their installed updater directly after the 5.5.4 Release asset and digest are verified.
Version 5.5.3 fixes automatic RadSec proxy enrolment so its client, credential set, and NAS assignment are created together, with unenrolment revoking the linked set. A single RadSec client with a missing/mismatched credential-set/NAS link now emits an actionable warning rather than stopping upgrades for every tenant; missing database schema or failed SQL remains fatal. The upgrader adds a restricted, detailed per-attempt debug transcript of release verification, file copies, Docker commands/results, migration operations and readiness/rollback steps, plus private container-log snapshots on failure. It also atomically replaces its own script at completion. There is no new database migration in this release; required historical SQL remains included.
Version 5.5.2 adds bulk Reset Usage on Users and MAC Auth; depleted-allocation details on the Dashboard, Reports and executive report/PDF; a full-width User-Specific Executive Report with reject analysis below; date-only Last Online columns; and a date-only Last Login column for administrators. Completed password-only and successful 2FA logins persist a per-administrator timestamp. The additive 20261011_admin_last_login.sql migration backfills existing accounts from completed-login audit events; failed 2FA and password-only attempts are excluded. No real usage records need resetting for this release.
Version 5.5.1 displays the installed source version in General Configuration, the Profile popup and the sidebar under Network Auth. The value comes from the installed VERSION file mounted read-only into the web UI, so it is not hard-coded into the pages. No database schema change is required for 5.5→5.5.1.
Version 5.5 adds correctly tenant-attributed login audit entries and a cross-tenant Global audit view; default-on dashboard auto-refresh; administrator-specific colour preferences with a platform default; updated Syslog/SIEM event fields, destination validation and a persistent auth-forwarding cursor; Docker-backed Global Server Health; refreshed guide and API routes; and Called-Station-ID capture/filtering. Fresh installs include the schema, while upgrades from 5.4 apply additive, tracked migrations that retain existing records.
For an existing published 5.5.2 installation, use the digest-verified 5.5.6 bootstrap after its Release asset is published; do not invoke the installed 5.5.2 ./upgrade.sh directly because it overwrites itself while running. For 5.5.3, 5.5.4 or 5.5.5, run the installed ./upgrade.sh --to 5.5.6 after verifying the published asset. For an existing published 5.5.1 installation, first upgrade to the published 5.5.2 asset using the 5.5.1 runbook, then use the 5.5.6 bootstrap from the installed 5.5.2 directory. For an existing published 5.4 installation, follow the historical upgrade runbook for the digest-verified 5.5 bootstrap first. The old 5.4 upgrader has a cold-start readiness race. VERSION is the committed source version; the Git tag and GitHub Release must use that exact number, without a v prefix (for example, 5.5.6). The upgrader downloads the named GitHub Release asset, verifies its published SHA-256, builds new images locally, backs up MariaDB and managed code, applies tracked migrations, then starts and checks services. It preserves .env, generated RADIUS files, Compose overrides and named volumes. Dean manually commits the code, creates the Release and attaches the tarball; committing the archive alone does not make it a Release asset.
For full installation instructions, feature breakdowns, and management guides, please visit the RadiusStack Wiki.
For a UniFi network, create one credential set and assign it to every AP/NAS in that network; upload the same client fullchain/key/password and server trust CA to the UniFi RADIUS profile. This simplifies lifecycle and is distinct from the AP TLS-close issue. Evidence: server verifies forced TLS 1.2 and TLS 1.3 mTLS locally; U6-LR firmware 6.7.57 still closes before ClientHello. This is not a firmware claim. Keep classic RADIUS as the safe fallback while feature work proceeds.