Self-hosted deployment
How Self-Hosted WISP Monitoring Deployment Works
Most WISP monitoring tools either run as a legacy desktop app or ship your network topology to someone else's cloud. TowerLens takes a third option: a backend that runs on your own network.
Try it in the live demo →Why self-host
A WISP's network map is sensitive — tower locations, customer counts, capacity headroom. A self-hosted backend means that data never leaves a machine you control, and nothing stops working if a vendor's cloud has an outage of its own.
How it's deployed
The real backend is a FastAPI + asyncio service backed by PostgreSQL: a database schema, a poll engine doing real ICMP/SNMP work, a REST API the dashboard talks to, and a scheduled RouterOS backup job. It installs on a machine you run — a small Linux box is enough — as part of a licensed TowerLens deployment, rather than as a source bundle you assemble yourself.
We're finalizing that licensing and install path now. Once it's live, setup is: install TowerLens, enter your license key, import your device list, and the dashboard switches from the browser-side simulation to real polling against your fleet.
What to prepare in the meantime
- Export your current device inventory from your existing monitoring tool or RouterOS/Winbox — the dashboard's 🔌 API panel shows the
devices.jsonshape it expects. - Decide where it'll run — a small Linux VM or box on your own network, not exposed directly to the public internet.
- Once you have real users, plan around the RBAC guide for setting up accounts and roles rather than a single shared admin login.
Related: How auto-discovery works · Config backup & restore