Project

Roadmap

RealNAS is forked from zVault (the community continuation of TrueNAS CORE) and is becoming a FreeBSD-native NAS manager that runs on vanilla FreeBSD instead of an appliance OS. The decoupling is in its final phase, and the 1.0 release will close the last blockers. This page tracks where the project is heading next: storage applications, upcoming capabilities, architecture-level decisions, and identity and data work. The final section lists what RealNAS will not ship.

Storage Applications and Workloads

S3-Compatible Object Storage

Native S3 API endpoint backed by ZFS, with multi-bucket layout, signed-URL access, and IAM-style policies. Lets RealNAS serve as a target for backup tools (Restic, Bareos, Veeam), build caches, container registries, and any application that expects an S3 surface. Distinct from the existing rclone cloud-sync integration, which makes RealNAS an S3 client; this makes RealNAS an S3 server.

Why not yet: SMB, NFS, and iSCSI are the documented core. Object storage is its own product surface (API, multi-tenancy, signed requests, lifecycle rules). Adding it before file storage hits the boring-and-stable bar for 1.0 fragments attention.
Unlock conditions: 1.0 ships. A decision between wrapping an existing implementation (MinIO, Garage) and a first-party emitter from the typed API contract.
Scope: Three to six months for a wrapper plugin (realnas-object). Twelve months or more for first-party.
Stay aligned: Optional package. Bucket data lives in ZFS datasets so snapshots, replication, and ACLs apply. Additive, not the primary storage surface.

AI and Machine-Learning Workloads

Storage optimized for LLM weights, training data, and vector databases. Workload profiles (record size, compression, atime, ZFS prefetch tuning) for sequential reads of large model files. An optional model-registry plugin that exposes a Hugging Face-compatible API and serves weights to GPU machines over SMB or NFS. An optional vector-database backend (Qdrant or Chroma) hosted in a jail.

Why not yet: AI workloads were not part of the inherited TrueNAS scope. Patterns (model registries, vector DB shapes, RAG stores) are still settling in the broader ecosystem. Building too early risks chasing fads.
Unlock conditions: A concrete operator running real AI workloads with RealNAS as the storage backend, articulating bottlenecks. The jails plugin tranche has shipped so service plugins have a deployment story.
Scope: Two months for workload profiles and documentation. Three to four months per service plugin (model registry, vector database).
Stay aligned: Optional package per service. Model and dataset storage stays in plain ZFS datasets, no proprietary format. Training and inference run on separate GPU machines that mount the NAS.

WORM and Immutable Archival

Write-once-read-many semantics for ransomware protection and compliance. Snapshots with enforced retention that cannot be released before the hold expires. Object Lock compatibility for the S3 surface. Dataset-level immutability flags for live data.

Why not yet: ZFS supports snapshot holds and a few immutability primitives, but the operator-facing WORM story (retention policies, dataset modes, ransomware-recovery flows, audit) needs design and lab testing.
Unlock conditions: S3-compatible object storage exists, since Object Lock builds on it. A ransomware-recovery smoke that drives the design.
Scope: Three to four months once the prerequisites land.
Stay aligned: Optional configuration on existing datasets, not a separate storage class. Retention and audit are inspectable and exportable.

Hybrid Cloud Tiering

Transparent migration of cold data to a cloud backend (S3, Backblaze B2, Cloudflare R2, Wasabi) with the hot tier on local ZFS. Lifecycle policies drive movement based on age or access patterns. Local restore on access. Builds on the existing rclone-backed cloud-sync infrastructure; new work is transparent tiering and lifecycle, not the cloud-client layer.

Why not yet: ZFS does not have native tiering. Implementation needs a userspace layer with a clear answer on partial restores, access latency, and what happens when the cloud backend is unreachable.
Unlock conditions: Decision on implementation: zettarepl-style scheduled migration, a FUSE-layer transparent tier, or rclone-mount integration. An operator with a clear hot/cold profile to design against.
Scope: Four to six months.
Stay aligned: Cold data is retrievable without RealNAS using standard cloud SDKs. No proprietary blob format. Operators can list and download cloud-tier objects directly.

Tape Archival (LTO and LTFS)

LTO tape drive and library integration. LTFS for portable archive volumes. Bulk migration of cold ZFS snapshots to tape with verifiable manifests. Suitable as a final cold tier for shops with existing LTO investment.

Why not yet: Hardware-gated (LTO drive or autoloader required). Narrow audience, but high value when the audience exists. The smoke story is hard without real hardware.
Unlock conditions: An LTO drive or autoloader reaches the dev bench. Decision between wrapping mt and bsdtar directly and integrating Amanda or Bacula.
Scope: Three to four months given hardware.
Stay aligned: Optional package. Tape is a backup tier, not primary storage. Manifests are inspectable without RealNAS.

Decentralized Storage Nodes

Run RealNAS as a node in IPFS, Storj, Sia, or Filecoin networks. Pin IPFS content. Optionally earn storage rewards on Storj or Sia. Bridge NAS-hosted data into decentralized networks. The existing rclone cloud-sync already supports Storj as a sync target; full node participation is the new work.

Why not yet: Each network has its own protocol and lifecycle. Token economics intersect with regulatory complexity. Most operators do not have a concrete use case beyond curiosity.
Unlock conditions: An operator with a real reason to run a node (data preservation, archival redundancy, public-good hosting). The plugin tranche pattern proven by jails. Legal review on token handling for the networks that include it.
Scope: Two to three months per network.
Stay aligned: Optional package per network, opt-in only. No token handling in core; node operations stay in the plugin.

Kubernetes Container Storage (CSI)

A Kubernetes Container Storage Interface driver exposing RealNAS NFS or iSCSI as Persistent Volumes to an external Kubernetes cluster. Snapshots and clones map to ZFS snapshots and clones. The driver runs in the Kubernetes cluster, not on the NAS; RealNAS does not become a Kubernetes host or run containers itself.

Why not yet: Kubernetes is a different ecosystem. Driver work is substantial. The audience is operators with a separate cluster who want a NAS-backed storage class.
Unlock conditions: At least one operator already using RealNAS from Kubernetes via manual NFS mounts, with clear pain points the driver would resolve.
Scope: Three to four months.
Stay aligned: NFS or iSCSI backend, already supported. The driver is a thin adapter; no Kubernetes-specific logic in the middleware. RealNAS continues to run on FreeBSD only.

Media Origin and Streaming Profiles

Workload profiles for the common media patterns: HLS or DASH origin, NVR and surveillance targets, Plex or Jellyfin libraries. Record-size, compression, and caching tuning per profile. Documentation of operator patterns, not new services.

Why not yet: Most of it already works. The gap is named patterns and tested presets rather than missing features. Application servers (Plex, Jellyfin, Frigate) run external to RealNAS and consume the storage.
Unlock conditions: Operator feedback on the profiles that matter most. Time to write the patterns up.
Scope: One to two months of profile and documentation work.
Stay aligned: Tuning and presets, not new services. Application servers remain external.

NVMe over Fabrics

NVMe over TCP, RDMA, or Fibre Channel for high-throughput block storage. Sits alongside iSCSI in the FreeBSD CTL stack. The gap is exposing target configuration through the WebUI.

Why not yet: iSCSI is the documented and tested block surface. NVMe-oF needs its own end-to-end smoke (target, initiator, multipath, persistent reservations) before it ships as a default-on capability.
Unlock conditions: An operator running NVMe-oF clients against a manual CTL setup, with concrete bottlenecks the WebUI integration would resolve. A 25 GbE or better NIC pair on the dev bench for the smoke.
Scope: Three to four months. Target configuration UI, connection-state visibility, multipath support, smoke matrix across transports.
Stay aligned: Extends the block-storage surface; does not replace iSCSI. Both coexist. Configuration is optional.

Backup Target Integration

Named integration profiles for Veeam (Hardened Repository over S3 Object Lock), Proxmox Backup Server, Restic, Borg, Bareos, and Bacula. Most of these tools already work over SMB, NFS, or S3; the feature is tested presets, retention defaults, and known-good configurations packaged as guided setups.

Why not yet: Existing protocols already serve these tools. Naming them as first-class integrations requires the underlying surfaces (S3, WORM) to ship first and the lab to validate each end to end.
Unlock conditions: S3 object storage and WORM ship. One representative deployment of each backup tool for testing.
Scope: One to two months per tool after prerequisites land. Presets, documentation, and smoke against the tool's repository protocol.
Stay aligned: Profiles and documentation, not embedded tools. RealNAS remains the target; the backup orchestrator runs on the operator's existing infrastructure.

Observability Surface

A Prometheus exporter for ZFS, pool, and system metrics. An OpenTelemetry collector for metrics, traces, and logs. Standard scrape endpoints so existing Grafana, Loki, and Tempo stacks integrate without bridging.

Why not yet: The current observability story is RealNAS-owned local diagnostics. Adding push or pull endpoints to external stacks needs careful design (auth, rate limits, optional scrape filtering) and a clear scope.
Unlock conditions: 1.0 ships. A decision between piggybacking on existing FreeBSD ports (node_exporter, zfs_exporter, otel-collector) and a first-party emitter from the typed API contract.
Scope: One to two months for a wrapper plugin. Three to four months for a first-party exporter.
Stay aligned: Optional package. No telemetry to project-controlled hosts. Endpoints are operator-configured and operator-scraped.

Modern OpenZFS Features

Surface recent OpenZFS additions in the WebUI and middleware: dRAID for faster resilver, block cloning via BRT (OpenZFS 2.2+), fast dedup (2.3+), and persistent L2ARC that survives reboot. ZFS already has these; the gap is exposing them.

Why not yet: The decoupling sprint focused on parity with the inherited TrueNAS feature set. New ZFS knobs need WebUI surface, validation, and smoke coverage before they're safe defaults.
Unlock conditions: 1.0 ships. Each feature has stabilized in the OpenZFS version FreeBSD 15.x carries.
Scope: One to two months per feature. dRAID first since it changes pool topology, block cloning second since it changes copy semantics, fast dedup and persistent L2ARC are smaller.
Stay aligned: Opt-in per feature, per pool. Defaults stay conservative. Existing pools are not migrated automatically.

Database Hosting Profiles

Workload profiles for hosting databases on ZFS. PostgreSQL, MySQL or MariaDB, time-series stores (TimescaleDB, InfluxDB, Victoria Metrics), Redis persistence. Same shape as the AI workload profile: record size, compression, atime, and recordsize-vs-pagesize alignment.

Why not yet: Existing operators tune these by hand. The work is documenting and packaging the tuning, not building new features.
Unlock conditions: Time to write the profiles up and validate against representative workloads.
Scope: One to two months total. A handful of profiles plus the smoke harness to verify them.
Stay aligned: Tuning presets, not a hosted database service. Databases run on the operator's application server and consume the storage.

Hypervisor Datastore Profiles

Workload profiles for serving as a hypervisor datastore. VMware ESXi over NFS or iSCSI, Proxmox via ZFS-over-iSCSI, XenServer over NFS. Persistent-reservation handling, queue-depth tuning, atime and sync semantics.

Why not yet: Most of it already works. The gap is documented patterns, tested presets, and the persistent-reservation story for shared block.
Unlock conditions: An operator with a representative ESXi or Proxmox cluster mounting RealNAS today, with concrete tuning gaps.
Scope: Two months. Profile documentation, persistent-reservation smoke, and known-good vSphere or Proxmox settings.
Stay aligned: Tuning and documentation, not hypervisor management. RealNAS is the storage; the hypervisor manages the guests.

Geo-Replication and Disaster Recovery

Cross-site asynchronous replication beyond the two-node HA story. Scheduled snapshot send across geographies. Documented RPO and RTO targets per replication policy. Replayable DR drills that exercise the cutover end to end.

Why not yet: HA is the closer goal and reuses much of the replication machinery. Geo-replication adds the consistency-and-cutover story that needs its own design and smoke.
Unlock conditions: HA ships. zettarepl already supports the underlying snapshot send; new work is geo-aware orchestration and the DR-drill harness.
Scope: Three to four months after HA. Replication policies, cutover automation, DR-drill smoke against a paired lab.
Stay aligned: Optional configuration on existing replication. Operators can run geo-replication without enabling HA, and the reverse.

SMB Direct and NFS over RDMA

Zero-copy filesystem protocols over RDMA. SMB Direct is SMB3 over RDMA; NFS-over-RDMA is the equivalent for NFSv4. High-bandwidth, low-latency for 25 GbE or 100 GbE deployments. Requires NIC and driver support.

Why not yet: Hardware-gated (RoCE or InfiniBand NIC required). Narrow audience today, growing as 25 GbE becomes cheaper. Smoke requires real hardware.
Unlock conditions: An RDMA-capable NIC on the dev bench. FreeBSD RDMA stack stable enough for the chosen protocol.
Scope: Three to four months given hardware.
Stay aligned: Optional configuration on existing SMB and NFS services. Falls back to TCP when RDMA is unavailable.

OpenStack Cinder and Manila

OpenStack volume drivers exposing RealNAS iSCSI as Cinder block volumes and NFS as Manila file shares. Sibling to the Kubernetes CSI driver, smaller audience.

Why not yet: OpenStack is a different ecosystem. Driver work duplicates much of the CSI shape for a smaller operator base. Lower priority than the Kubernetes CSI entry above.
Unlock conditions: The Kubernetes CSI driver has shipped and the patterns generalize. An OpenStack operator with a working RealNAS-backed deployment.
Scope: Two to three months once CSI exists and the patterns are reusable.
Stay aligned: Drivers run in the OpenStack control plane, not on the NAS. RealNAS continues to run on FreeBSD only.

Continuous Data Protection

Block-level journaling for point-in-time replay. Catches data corruption or accidental writes between scheduled snapshots. Distinct from ZFS snapshots, which are point-in-time but not continuous.

Why not yet: CDP needs a block-journal layer ZFS does not provide today. Implementation requires either a userspace shim or a significant ZIL extension. Most operators are served by frequent snapshots plus snapshot replication.
Unlock conditions: An operator with a concrete need that snapshot frequency cannot satisfy. Decision on implementation approach.
Scope: Six to nine months. Closer in size to HA than to a workload profile.
Stay aligned: Optional configuration on existing datasets. CDP-protected data is still recoverable via standard ZFS tools without the CDP layer.

Upcoming Capabilities

High Availability and Failover

Two-node active/passive failover with shared-disk JBOD or replicated storage. Inherited from TrueNAS as a failover.config plugin stub.

Why not yet: A two-node test fixture is a prerequisite. Most production HA bugs only surface under split-brain, network partition, and disk-path failures. Those need lab evidence, not unit tests.
Unlock conditions: The hardware smoke tier has been running on every release candidate for at least two quarters. A two-node SAS-attached JBOD or equivalent reaches the dev bench. The typed API contract has stabilized so the HA controller has a versioned surface to call.
Scope: Six to nine months minimum. HA coordinator plugin, fencing, shared-secret rotation, boot-environment-aware failover, split-brain detection, and smoke against simulated and real failures.
Stay aligned: Optional package (realnas-ha), not a core feature. The single-node install continues to work without any HA awareness. Operators can detach HA cleanly and run as a single node again.

bhyve Virtual Machines

Run guest VMs on the NAS using bhyve. Inherited from TrueNAS; the vm namespace is currently disabled.

Why not yet: High demand from the FreeBSD community, but bhyve management is its own product surface: disk-image lifecycle, networking, console access, snapshot and clone integration, VNC. Building it well is a multi-quarter project.
Unlock conditions: The jails tranche has shipped and stabilized through at least one release cycle. Jails are the cheaper proof of optional compute on the NAS; once that pattern works, bhyve reuses the same plugin shape.
Scope: Four to six months. bhyve plugin graduates from disabled, disk-image storage on ZFS, VNC bridge through the WebUI, snapshot and clone integration with the existing dataset story, and a vm-e2e smoke.
Stay aligned: Optional package (realnas-vms). No bundled OS images. No click-to-deploy marketplace.

KMIP Key Management

External key management protocol for encrypted pools and datasets. Would replace the local pwenc_secret for shops that already run a KMIP server.

Why not yet: Small in scope but low demand. The shops that need KMIP are the ones least likely to be early RealNAS adopters. Without a design partner, the result would satisfy the spec but not survive contact with a real Thales, SafeNet, or HashiCorp Vault deployment.
Unlock conditions: At least one operator with a working KMIP deployment willing to be a design partner.
Scope: Two to three months once a partner exists. Plugin shell, key-rotation hooks, smoke against a containerized KMIP server.
Stay aligned: Optional package. Local pwenc_secret remains the default. KMIP is opt-in per pool.

Fibre Channel

Expose ZFS zvols as Fibre Channel LUNs via CTL. Inherited from TrueNAS; useful for shops with existing FC fabrics.

Why not yet: Hardware-gated (FC HBA required), narrow audience, and the smoke story is hard. Fabric simulation is a research project on its own.
Unlock conditions: An FC HBA reaches the dev bench. Without one, no honest evidence is possible.
Scope: Three to four months given hardware. Smaller than HA because most of CTL is already inherited. The work is decoupling the FC half from the iSCSI half.
Stay aligned: Optional package. Must not regress iSCSI smoke when installed alongside.

NIS Directory Service

Sun-style network information service. An inherited stub, long superseded by LDAP for the use cases it covered.

Why not yet: The realistic path is removal from the UI and API rather than graduation. Listed here so the decision is explicit and not maintained as a stub indefinitely.
Unlock conditions: A real user request, otherwise removal is the default. Until that happens, the NIS page stays hidden and the API rejects enable attempts cleanly.
Scope: One week to remove. One month if anyone needs it graduated.
Stay aligned: Either path keeps disabled state clean. No leak into generated config.

Enclosure and SES Management

Read drive-bay layouts, blink fault LEDs, map slots to ZFS vdevs. Hardware-provider plugin.

Why not yet: Hardware-shaped like Fibre Channel. Needs an enclosure with SES support.
Unlock conditions: A SES-aware enclosure reaches the dev bench. Same trigger as FC, likely the same hardware moment.
Scope: Two months given hardware. Mostly adapter work over sesutil.
Stay aligned: Optional package. Degrades silently when no SES-capable enclosure is present.

Architecture-Level Projects

Daemon Language Migration

Replace realnasd (Python) with a typed, compiled equivalent in Go or Rust.

Why not yet: Python has been load-bearing for the entire decoupling. A language migration is years of work and only makes sense if Python is actually blocking something: slow plugin load, memory pressure, or deployment friction. Today none of those bite.
Unlock conditions: One of: plugin load time becomes a release-blocking complaint; Python 3 end of life forces the migration; or the daemon needs a shape that is hard to express in Python, such as zero-downtime upgrade with state hand-off.
Scope: Eighteen months minimum for a faithful port. Realistic path is a hybrid: boring core in Go, plugins still in Python. Slower, but does not ship a regression cliff.
Stay aligned: Plugin contract remains stable across the migration. Operators see no behavior change. The typed API contract gives the daemon a clean external surface to preserve while internals change.

REST API Surface

A REST shim over the existing WebSocket and JSON-RPC API, so plain curl automation can use the same operations the WebUI does.

Why not yet: The WebUI does not need it. CLI users have midclt. Until a third-party integration shows up that cannot use WebSocket, the REST surface is speculative.
Unlock conditions: The typed API contract is published. Once a versioned schema exists, generating a REST shim from it costs days, not months.
Scope: One to two months after the schema lands.
Stay aligned: REST is additive, not a replacement. The WebSocket API remains the primary contract.

Container-Native Packaging

Ship realnasd and the WebUI as OCI containers, runnable on a FreeBSD container runtime rather than as a pkg install.

Why not yet: Conflicts with the FreeBSD-owns-the-OS boundary if it leads to running on Linux. Does not conflict if it stays a packaging alternative for FreeBSD. The user benefit (slightly easier upgrade rollback than boot environments) does not clearly outweigh the architectural drift.
Unlock conditions: A FreeBSD container runtime ecosystem matures to the point operators actually use it. If FreeBSD ports starts shipping reference container images for its own services, that is the signal.
Scope: Unknown until the unlock condition is met. The daemon containerizes easily. The orchestration story for ZFS, Samba, NFS, SMART, and network from inside a container is its own product.
Stay aligned: Even if shipped, pkg install remains the supported default. Anything that requires running the host kernel from a container layer is out.

WebUI Framework Migration

Replace the inherited Angular WebUI with a different framework such as React, Solid, or Svelte.

Why not yet: A full rewrite costs roughly 100,000 lines and dozens of pages of inherited UX patterns. That cost dwarfs the user-visible benefit. Listed here so the question has a place to land instead of recurring.
Unlock conditions: Angular itself blocks something specific: a feature that cannot ship, a security gap upstream cannot close, or LTS support ending without a viable upgrade path. Developer ergonomics alone is not enough.
Scope: Two to three years for a faithful port. Realistic only as a gradual model where new pages start in the chosen framework while old pages stay Angular, made possible by the typed API contract.
Stay aligned: No half-migrated WebUI in the default install. If both frameworks coexist, separate routes with consistent UX, not interleaved within a page.

Identity and Data

OIDC, Tailscale, and SSO

Why not yet: Local users plus 2FA is the MVP. The SSO question is open post-1.0.
Unlock conditions: At least one identity provider has enough traction in the FreeBSD and homelab space to be worth integrating against. Tailscale is the most likely candidate today.
Scope: Two to three months for a single IdP. Each additional IdP is its own integration.
Stay aligned: Local users plus 2FA remains the supported default. SSO is opt-in and configured per install. Account recovery does not depend on the IdP being reachable.

First-Class Backup and Restore API

Config backup and restore as a named middleware capability, not a shell-level dump of /var/db/realnas. The inherited shape exists. The API surface and WebUI flow do not.

Why not yet: The boot-environment plus ZFS snapshot model already covers most of this implicitly. A first-class backup API would be cleaner, but operators understand boot environments and snapshots today.
Unlock conditions: The typed API contract lands. Schema-driven backup payloads are easier to build than hand-rolled ones.
Scope: Two months once the schema exists.
Stay aligned: Backup payloads stay inspectable plain JSON and SQLite, not a proprietary blob. Operators can read and edit backups outside RealNAS.

Not Planned

These are different from the items above. They are settled decisions, not deferred work.

Telemetry, crash reporting, activation servers, license-key check-ins, or project-controlled analytics. The active-source telemetry scan is part of CI for a reason.
App-store or plugin-catalog UI. Optional plugin packages are installed individually via pkg, not browsed and clicked.
Linux port. This project exists because FreeBSD and ZFS matter.
Custom appliance ISO or installer image. FreeBSD's own installer is the supported path. RealNAS is pkg install-able on top.
Patched FreeBSD kernel. RealNAS runs on stock published FreeBSD or it does not run.
Proprietary on-disk formats or undocumented export paths. ZFS, SMB, NFS, and FreeBSD account formats are the substrate. If RealNAS goes away, the data is still reachable without conversion.
Community-edition versus enterprise-edition split. Paid services may exist around the product, but features are not gated. The free build is the only build.
Revenue models based on collecting operator data.
Broad support claims for directory services, HA, hardware health, or encrypted-pool conversion before tests and docs exist.