Roadmap

This page describes intent. The near-term items are work the project considers in progress and expects to ship. The mid-term items are reachable from where we are. The long-term items are doors held open: capabilities the architecture deliberately does not preclude, and which may become real work as the project and the community grow. Nothing on this page is a promise.

---

Where the project is now

The current focus is hardening and architecture-contract enforcement. The management plane runs as a userspace daemon on FreeBSD 15.x with the standard rc.d integration; the webui talks to it over a WebSocket; ZFS, SMB, NFS, users, snapshots, alerts, and boot environments are managed end-to-end. The work in flight is reducing the surface that does not belong to the OS, finishing the offline-install story, and producing a clean release-cadence pipeline against FreeBSD’s own.

Near term: months

• Stabilize on FreeBSD 15.x. Track FreeBSD’s point releases without surprise. Each point release should require small, predictable work; not a months-long port.
• Full smoke suite green. An end-to-end smoke test that exercises pool creation, share definition, snapshot, scrub, alert, update, and boot environment, against a fresh install of the latest FreeBSD point release.
• Signed pkg repository. A dedicated mirror for RealNAS-built packages, signed with a key whose fingerprint is published, so upgrades are verifiable end to end with pkg’s native signature mechanism.
• Documentation expansion. The site you are reading is the start. The manual will fill out with operator-tested recipes for common deployments.
• Plugin surface recovery. A modest set of opt-in plugins for adjacent services (backup integration, monitoring exporters, certificate automation), restored cleanly and shipped as separate packages rather than as part of the core.

Mid term: quarters

• Per-subsystem jail option. Allow Samba, NFS, and the proxy to run inside FreeBSD jails with resource limits. Opt-in, off by default. Useful on hosts that do more than one thing.
• Capsicum sandboxing for daemons. Where a worker does a small, well-defined set of operations, sandbox it under Capsicum.
• First-class audit log. A structured local audit trail of configuration changes and authentication events, with a documented format, exportable to a remote collector.
• Replication ergonomics. Better defaults for zfs send / receive relationships, including SSH key management, bandwidth limits, and scheduling. The mechanism stays standard ZFS replication; the configuration surface gets nicer.
• Backup integration. Native integration with at least one community-favored offsite backup tool, treated as an optional plugin rather than a core dependency.
• Certificate automation. Optional plugin for ACME issuance and renewal, surfaced in the UI but implemented by well-established external tooling.

Long term: doors held open

These are not commitments. They are capabilities the architecture deliberately does not foreclose, and which become work the project would consider taking on as resources allow.

Distributed storage

ZFS handles single-host storage extraordinarily well. Multi-host storage (coordinated quorum, transparent failover, distributed replication topologies) is a different problem. The architecture does not assume a single host. A future multi-host coordination layer, layered on top of ZFS replication, is reachable from where we are. We are not building it today.

Workloads beyond classic file serving

ZFS’s snapshot, clone, and recordsize semantics are unusually well-suited to several workloads beyond home-directory and document storage:

• Datasets tuned for model checkpoints, where the cost of keeping every checkpoint is dominated by the deduplication and snapshot story.
• Datasets sized for vector stores and embedding tables, where atomic snapshots of a corpus are operationally valuable.
• Datasets serving as the durable substrate of training-data lakes, where lineage and reproducibility matter and ZFS makes both cheap.

None of these require a different RealNAS. They require recipes, tuned defaults, and documentation. The architecture is ready when the demand is.

Operations at organizational scale

The base RealNAS install is already suitable for production deployment by operations teams running serious infrastructure: standard ZFS, standard FreeBSD, standard operational tooling, no hidden state, no telemetry, no vendor accounts. The items below are additions for environments with specific large-organization requirements, not prerequisites for treating RealNAS as production infrastructure.

• High availability pairing. A second host that can assume the role of the primary on failure. Standard problem, well-understood patterns; the architecture does not preclude it.
• KMIP-managed encryption keys. ZFS encryption with key release brokered by a network key manager, for environments that require it.
• Fibre Channel and other SAN-side protocols. If the demand is real, the FreeBSD stack supports them; integration into the management layer is engineering, not a research project.
• Audit-log streaming. Push the audit trail to an enterprise SIEM in real time.

Commercial offerings

The project intends to be sustainable. The shapes that sustainability could take, all consistent with the freedom commitments:

• Paid support contracts. Response-time guarantees, named contacts, escalation paths, with the technical product unchanged from the free build.
• Signed-mirror subscriptions. A paid tier of the signed-pkg repository with SLAs and pre-release access; the free signed mirror continues to exist.
• Hosted instances. For operators who want the architectural posture but not the closet. Clearly labeled, operator-controlled keys, exportable to self-hosted on demand.
• Certified hardware. An optional program for vendors that want to test against RealNAS and label devices as having passed.
• Sponsored development. Operators that need a specific feature can fund its development; the result lands in the open tree like any other contribution.

None of the above subtract from the free build. They add to a base that continues to do its job on its own.

What the project deliberately will not chase

• Features that require closed binary components in the default path.
• Architectures that put the project in a privileged position relative to the operator (license servers, mandatory accounts, online activation).
• Monetization patterns that depend on the operator’s data being legible to the project.
• Lock-in mechanisms (proprietary formats, undocumented protocols, account-tied configurations) that would make leaving expensive.
• Marketing claims about scale or performance that cannot be reproduced by a competent operator on commodity hardware.