Questions, answered

Yes. FreeSDN is open source under AGPL-3.0 with no per-device fees, no seat licensing, and no cloud subscription. You self-host it and own your data. Every edition (Lite, Pro, and Max) is free.

FreeSDN unifies networking (switches, access points, WiFi, VLANs, PoE), firewalls and gateways, IP cameras and NVRs, VoIP/PBX, access control, compute (Proxmox), and storage (TrueNAS): 10 modules across 13 vendor adapters, under one dashboard and one API.

13 vendor adapters today: TP-Link Omada, Ubiquiti UniFi, MikroTik, OpenWrt, OPNsense, pfSense, Hikvision, ONVIF, FreePBX, Grandstream, Proxmox, and TrueNAS. A typed plugin SDK lets you add more.

Every device write rides a staged-change pipeline: changes are staged, then applied behind a dual gate (read-only flag plus an explicit force), with an atomic claim, full audit record, and saga-style rollback. Nothing touches device config without double confirmation.

Yes. FreeSDN uses application-layer, fail-closed tenant isolation (organization → site → device) with role-based access control (5 assignable roles) and per-user site grants. Credentials are encrypted at rest with Fernet (AES-128-CBC + HMAC-SHA256). See the Security & Trust page for the honest posture, including what is and isn't claimed.

FreeSDN is a pre-production / testing release intended for evaluation, testing, and homelab use today. It is not yet recommended for production or business-critical deployments; production readiness will be announced in a future release.

Yes. FreeSDN ships a typed plugin SDK with a sandboxed, permission-declared runtime and a signed marketplace, plus Fabric, a universal app-interconnect that wires events to actions across apps. There's also a multi-provider AI assistant with a permission-gated tool registry.

No. FreeSDN is fully self-hosted and air-gappable. There is no telemetry requirement and no cloud dependency. The public demo even runs entirely in your browser with zero backend calls.

A Linux host with Docker and Docker Compose. The always-on core is PostgreSQL, TimescaleDB, Valkey, the FastAPI application, a Celery worker, the Celery Beat scheduler, a database backup sidecar, and a Caddy edge that obtains HTTPS certificates automatically. Optional profiles add IO workers, monitoring, camera restreaming, connection pooling and off-site disaster recovery.

It depends on the tier you install. Lite runs comfortably on a small virtual machine with 2 CPU cores and 4 GB of memory for a homelab or a single site. Pro and Max add more workers and queues for larger fleets and multi-site deployments. Time-series data is the main thing that grows, so size the disk for how long you want to retain metrics and flow records.

They are deployment sizes, not commercial plans. Every tier is the same software under the same licence, and all of them are free. The difference is which workers run and which queues they consume, chosen with an install flag so a small deployment does not pay for capacity it will never use.

Upgrading is a deliberate action: pull the new tag, rebuild, restart. There is no automatic updater. Database migrations run on start. Take a backup first, as with any infrastructure component. Breaking changes are called out explicitly in the release notes rather than being left for you to discover.

Yes, and there are two formats on purpose. A .fsdn file carries configuration with no secrets in it, which is the one you can hand to someone else. A .fsdnvault carries everything including the credential vault, sealed with a passphrase and re-keyed on restore. A vault backup can rebuild an instance from a fresh install.

No, and that is deliberate. It sits in front of them. Your Omada controller, UniFi console, OPNsense firewall and Proxmox cluster keep running exactly as they do now. FreeSDN registers each one, reads through its API, and gives you a single place to see and act across all of them.

No adapter currently claims live-validated writes. Reads are proven against real hardware, while writes are staged and tested against mocks. Access Control is disabled by default and cannot yet be enabled. There is no service level agreement of any kind. These limits are published on the site and in the product rather than being discovered in production.

Every integration publishes how well proven it is, kept separate for reading and for writing because those carry very different risk. A label cannot claim live validation without recorded evidence from real hardware, and an automated check in continuous integration enforces that. The point is that you can tell how much to trust a given integration before you rely on it.

You are told. A write that the device rejects is reported as a failure rather than an acknowledgement, which sounds obvious and is the single most common defect in tools of this kind. Some vendor APIs answer with a success status code and a body that says no, so the result is inspected rather than the status code alone.

Yes. A platform-wide flag refuses every device write, and it is the safe default for anyone running outside the shipped Compose stack. Even with writes enabled, each apply needs an explicit per-request confirmation, and destructive actions need their own confirmation on top.

Access is controlled by five roles across an organization, site and device hierarchy, with strict-lower assignment so an account can never create one more powerful than itself. Per-user site grants narrow further within a role, so an operator responsible for two branches sees only those two.

Encrypted at rest in the database using Fernet. They are redacted centrally on every adapter read, so a vendor API that returns a pre-shared key or a SIP secret in its payload does not pass it through to the browser or into a log line.

If you run FreeSDN internally, which is the normal case, it imposes no obligations on you beyond keeping the licence and notices intact. The obligation appears if you modify FreeSDN and offer it to others as a network service, in which case you must make your modified source available to those users. The edge agent and the plugin SDK are MIT licensed, so building on those carries no copyleft.

No. There is no paid tier, no feature held back behind a licence key, and no open-core split. Everything in the project is in the public repository under AGPL-3.0.

Through GitHub issues and discussions in the public repository. There is no commercial support contract and no service level agreement today, which is a statement of fact rather than a negotiating position, and it should factor into whether you put this in front of business-critical infrastructure yet.

Releases use calendar versioning in the form YY.MM.PATCH, targeting a monthly cadence. Security patches ship as patch increments as soon as they are ready rather than waiting for the cycle.

Yes. New vendor support goes through the adapter contract, which sets out what an integration must implement and how it earns its maturity label. The plugin SDK is the other route, and it does not require changes to the core. Both are documented, and the contract is deliberately explicit about evidence rather than intent.

Only if you configure a provider that requires it, and it is off until you do. Multiple providers are supported including local models through Ollama, so the assistant can run entirely on your own hardware. Tool access is permission gated, and there is a global kill switch plus per-organization policy.