Built for the review that comes before the rollout
One control plane across switches, firewalls, cameras, VoIP, hypervisors and storage, with the identity, isolation, audit and recovery controls a security review asks for, and release gates an evaluator can run.
Identity and access
Single sign-on over OIDC, verified end to end against a live identity provider. TOTP multi-factor with recovery codes. Five assignable roles in a strict hierarchy that blocks privilege escalation at the API layer, plus per-user site grants for operators who should only see their own sites.
- OIDC SSO and LDAP factors
- TOTP MFA with recovery codes
- Five roles plus per-user site grants
- Scoped API keys with a hard permission ceiling
Tenancy and segmentation
Organization, site and device form the hierarchy every query is scoped against. Isolation is enforced in the application layer and fails closed: a caller with no verified organization gets nothing back rather than everything. A CI gate makes an unclassified tenant table impossible to merge.
- Organization to site to device
- Fail-closed tenant scoping
- Per-user site grants across site-scoped modules
- CI gate on tenant classification
Change safety
No configuration reaches a device from a single click. Every adapter write is recorded in a staging table and applied only behind a platform-wide flag and an explicit per-request confirmation, with a per-action confirm on deletes. Operators review what will change before anything does.
- Staged writes through one chokepoint
- Two independent gates before apply
- Per-action confirmation on deletes
- Before and after diffs on every privileged action
Audit and accountability
Privileged actions are recorded with the user, organization, address, user agent, resource and the change itself. Audit records are anchored in an HMAC chain with verification snapshots, so tampering with history is detectable rather than merely discouraged. Retention is configurable.
- Tamper-evident HMAC audit chain
- Verification snapshots
- Configurable retention
- Exportable for review
Resilience and recovery
The high-availability profile runs streaming replication with a qualified failover drill covering standby restart, volume recreation and manual promotion. Encrypted backup and restore is exercised on every release, including a restore into a clean target where old sessions are refused after the key cutover.
- Streaming replication and manual promotion
- Encrypted backup with passphrase sealing
- Restore into a fresh instance
- Qualified as a release gate, not a feature claim
Data sovereignty
FreeSDN is self-hosted on infrastructure you control. Device credentials are encrypted at rest, secrets are redacted from adapter responses before they leave the API, and nothing phones home. There is no telemetry to disable and no vendor cloud in the path between you and your own equipment.
- Runs entirely on your hardware
- Encrypted credential storage
- Secret redaction on every response
- No telemetry and no callback
Release gates
What has to pass before a release exists
These run against the real stack and the real artifacts, not a staging approximation. The upgrade gate uses a database created by the previously published image, because an upgrade test against a stand-in proves nothing about your volume.
| Gate | What it exercises | 26.10.0 |
|---|---|---|
| Fresh install acceptance | The published tree is installed and driven as a user: login, dashboard reads, report downloads and concurrent load across five queues, with the stack required to come up healthy. | 14 checks |
| In-place upgrade acceptance | The new release starts on a database created by the previous published image. Collation, sort order, the postgres uid, data checksums and a collation-dependent index must all survive unchanged. | 19 checks |
| Database runtime qualification | Logical migration with content, permission and index verification, rollback to the old image, and the refusal controls that stop an incompatible cluster being started at all. | 22 cases |
| High availability drill | Physical replication bootstrap, streaming delivery, standby restart, container recreation against the intended volume, and manual promotion permitting new writes. | 5 cases |
| Image vulnerability scan | All fifteen shipped images, scanned with unfixed findings included and suppressions disabled. Thirteen are built from source rather than pulled. | 0 actionable findings |
Deployment
Three profiles, one codebase
The same release runs at every size. Tiers differ in which workers run and which queues they consume, so growing a deployment is a configuration change rather than a migration to a different product.
Lite
A single host running the core stack. Suited to one site, a lab, or an evaluation you intend to keep.
Pro
Separated worker tiers and queues for larger fleets, with the scheduler and collector carrying their own capacity.
Max
The full profile: dedicated queues, the observability tier and the high-availability topology with replication and failover.
13 vendor adapters and 10 product modules are present in every tier. There is no feature-gated edition and no per-device licence.
Scope
What we do not claim
A capability list is only useful if the gaps are in it too. These are current as of 26.10.2 and are enforced in the product rather than left to the reader to discover.
No integration claims live-validated writes
Reads are proven against real hardware. Writes are staged behind two gates and exercised against recorded captures and mocks. The product labels every integration with its read and write maturity separately, and a CI ratchet refuses to let a label claim live validation without a recorded capture to back it.
SAML single sign-on is deliberately unavailable
The implementation exists but is disabled, because the assertion verifier is not yet hardened against signature-wrapping attacks. It will be enabled when that is done and not before. OIDC is available and verified end to end against a live identity provider.
Platform support is linux/amd64
The server stack is built and qualified for linux/amd64. The edge agent is exercised end to end on Ubuntu; Windows service-manager and macOS launchd integration are implemented but not qualified to the same standard, and macOS on ARM64 is experimental.
Local backup health is not proof of off-site recovery
A green local backup check confirms the backup was written and sealed. It does not verify that an off-site copy completed or that a restore from it will work. Treat off-site verification as your own responsibility and rehearse it.
See it running in your browser
Explore the full FreeSDN dashboard with realistic sample data, no signup, no backend. Then install it in minutes.