How it works
Farava Platform is installed on one server owned by the ISP. Every ISP has its own independent installation; there is no shared server and no cloud dependency for authentication or accounting. If the server loses its internet connection, your subscribers still connect.
The parts
Section titled “The parts”| Part | What it does |
|---|---|
| Admin panel | Web interface for staff: customers, plans, finance, NAS devices, reports |
| API | The core logic used by the admin panel and the customer portal |
| FreeRADIUS | The server your routers (NAS) talk to for authentication and accounting |
| Background workers | Usage processing, quota and suspension enforcement, vouchers, housekeeping |
| PostgreSQL | The database — the single source of truth for everything |
The two main paths
Section titled “The two main paths”Authentication: router → FreeRADIUS (UDP 1812) → username, subscription, and plan check → accept or reject back to the router, with the speed limit attached.
Accounting (usage): router → FreeRADIUS (UDP 1813) → session and usage recorded → what you see under Sessions and Usage in the panel.
These are separate paths. A subscriber who authenticated successfully but whose accounting data does not reach the system shows as Offline in the panel. That is why both paths are checked after installation.
The key difference from DeltaSIB and SAS-Radius
Section titled “The key difference from DeltaSIB and SAS-Radius”Farava does not manage the router directly and never connects to the RouterOS API. Everything goes through the RADIUS protocol itself:
- Speed limits: Farava sends a
Mikrotik-Rate-Limitattribute in the Access-Accept, and MikroTik creates the dynamic queue itself. - Disconnects and plan changes: Farava sends a RADIUS Disconnect or CoA request, and MikroTik ends or updates the session itself.
As a result, the system never needs your router’s admin username and password, and everything it does on the network can be traced in RADIUS packets.