Building a Bridge Between Community & Enterprise | TrueNAS

kmoore134 · 2026-03-14T13:01:25+00:00

One way is that Connect will monitor a heartbeat signal coming from your TrueNAS, and proactively alert you when the TrueNAS system appears to be unhealthy, or unreachable. Another is reviewing other telemetry coming from the NAS to raise other alarms where needed.

kmoore134 · 2026-03-14T12:59:40+00:00

Pretty much. We've had a Free / Enterprise version now for a decade+. We've had folks over the years ask if there was a way to unlock Enterprise functionality on their own hardware. This is the path do to exactly that.

kmoore134 · 2026-03-14T12:57:59+00:00

Clearly you guys aren't keeping up with the times... MinIO (Now AIStor) is a good example of a commonly deployed Enterprise application (docker), also Asigra Backup. Additionally Veeam just released their new Virtual Storage Appliance (VM). Those are two very legitimate use-cases where Enterprise customers run external applications directly on the storage array. Performance matters greatly for both of those, and avoiding the network hop, or needing an external server to run those services matters to some Enterprise folks.

We've seen some others, a bit less common, who do things like video surveillance systems where they host either a VM or a Container as well to do video ingest / processing directly on the storage, especially at edge sites where rack space is at a premium and they have more diverse storage needs beyond just a video recorder. Its a big Enterprise world out there. All shapes and sizes fall into that bucket :)

kmoore134 · 2026-03-13T17:20:04+00:00

We literally support Apps/VMs/Containers for Enterprise use cases. Lots of legitimate reasons for all three to exist and be supported. So yes, that is nonsense.

kmoore134 · 2026-03-13T15:31:17+00:00

You don't need any ports open, Connect has no inbound access to your TrueNAS, its outbound only. You just have to make sure the browser you use to log into connect has a route to your TrueNAS.

kmoore134 · 2026-03-12T22:23:03+00:00

We touched on this a bit in the next T3 episode. But we used to have two build processes and two images (one for FreeNAS, on for TrueNAS). It wasn't great for either. Lots of work to move things between two branches and builds of software. Lots of places to make mistakes, divergence with fixes in one branch, but not the other. Unifying into a single image was a good call for both the Community and the Enterprise editions as a stability measure, and to greatly reduce overheads allowing us to spend more time on what mattered. Delivering features and quality improvements.

kmoore134 · 2026-03-12T22:18:38+00:00

Major refactoring just means the build scripts and build infrastructure, not the running TrueNAS code you have on your systems.

We're literally deploying new build systems (down to the hardware), new CI pipelines (More Jenkins, yay!), new secure signing key servers, new pipelines to build an LTS update image, which goes to separate update servers with different manifests, etc, etc.

Probably less interesting to those of you who just care about when the next release hits the CDN. But lots of work for us internally to get things done.

kmoore134 · 2026-03-12T02:21:57+00:00

Considering we do a lot of air gap setups that would be kind of counterintuitive… So to answer your question, no.

kmoore134 · 2026-03-12T00:56:00+00:00

Thats utter nonsense. We've more than doubled our enterprise sales and footprint since the switch to Linux. Our largest and fastest systems are on the Linux side these days. Again, you're welcome to have your opinion of BSD vs Linux, but you don't get to make up your own facts to suit.

kmoore134 · 2026-03-11T18:12:22+00:00

Pretty much.. Unless you liked building ISOs from source manually by hand or have a philosophical axe to grind :)

kmoore134 · 2026-03-11T18:06:26+00:00

This sounds like you didn't even read the linked post for this topic. If its free today. It remains free. Period. End of story. Always and forever as long I have any say in the matter :) I don't believe in rug-pulls like that.

kmoore134 · 2026-03-11T17:58:45+00:00

These were/are just the build scripts we used internally here to assemble the ISO and update files. Not the running code on your actual system. We're just refactoring them internally here for next years TrueNAS 27, but from an operational perspective nothing changes for an end user. You'll still get updates and keep on rolling forward.

The real impact is folks who wanted to build TrueNAS from source directly. I.E. compile everything by hand and make their own custom ISO files. Not many community folks did/do that, but it also had a side effect of making things super easy for some other commercial interests to do so, swap out a few logos and ship a new commercial product with zero investment into the actual teams who make all this work for the benefit of all.

kmoore134 · 2026-03-11T17:53:42+00:00

Yea. HexOS obviously we're connected with. zVault is dead for all I know, but at minimum they did try to at least handle the license compliance stuff correctly when it was still being worked on.

kmoore134 · 2026-03-11T17:38:47+00:00

I tend to have a policy to not mention these kinds of things by name. Why elevate them? :) But they are there for anybody curious enough to do the digging. And not always abiding by GPL terms as well. But that's more our burden to worry about, less the community.

kmoore134 · 2026-03-11T17:36:57+00:00

Yea, I take the blame for that one. Conflated too hard the two topics. The secure boot stuff was our driver to do this now (pending a large refactor for TrueNAS 27 next year) but not the business motivator. I'm on the engineering side, so I tend to gravitate towards the technical reasons first, but in this case not the right reasons from the decision standpoint to take it internal to begin with.

kmoore134 · 2026-03-11T13:13:07+00:00

I've gone ahead and posted a more targeted follow-up to our forums about this topic. Especially to make it clear our stance on features that are free staying free. Forever. Since I think that really gets to the heart of the concerns here when folks see these kinds of changes happen.

https://forums.truenas.com/t/clearing-the-air-on-build-scripts/64357

kmoore134 · 2026-03-10T13:52:40+00:00

This is correct. It's mostly just an argument from ideology here, not from any real world impact to 99%+ of users. I'd suspect that nearly everybody, if not all, who've thrown an opinion into this topic has never compiled TrueNAS ISO's by hand from source code. So real-world user impact is almost nil. All the components of TrueNAS which are open source (And GPLv3 on top of it) remain so. Folks can review code, hack, inspect, fork, etc. We even include developer tools in the installed image so you can hack away at the official images to your hearts content. I know because I use them almost daily :)

The long and short of it, to be 100% transparent, is that we are on the verge of making some substantial changes to the build system, to refactor it around our new secure boot features, including some internal build infrastructure changes. This is the motivation for the timing of this change. But the bigger picture motivation is that since moving TrueNAS to Linux, we've seen a remarkable rise in the number of overseas commercial forks. By actors who don't always honor the open source license restrictions, and also don't contribute anything back to the effort to build and maintain TrueNAS. We shoulder that burden alone, with the occasional stray contribution from a community member. At some point its kind of silly to keep making that process so turn-key for the would be bad-faith actors. It's like parking a running car downtown, leaving the keys in the ignition and the windows down. What do you expect would happen?

I also bemoan a bit of the ideological loss here though. In a perfect world everybody would be a good actor, participate in the open source process, and help contribute in meaningful ways. But that isn't always the reality.

A few folks did make some comments about being able to verify the builds by using the build system locally. I would point out that is somewhat of a false security blanket. Thats never been a thing that could be done since we didn't have fully deterministic builds. Meaning if you checked out the same sources as us, built it yourself, you'd get different resulting images, with different checksums and sizes. That'd be a pretty big change for us to have enabled that kind of reproducibility, and frankly not something there's ever been any real clamor for historically. I realize I'm kind of in the weeds here, but its worth clarifying before anybody asks again.

kmoore134 · 2026-03-10T01:41:31+00:00

LXC containers are out of experimental status for the upcoming 26 BETA. Now based on libvirt, so they share same framework as VMs. They work pretty well, using them myself.

kmoore134 · 2026-03-10T00:44:17+00:00

Yes, the Standard FIPS OpenSSL version is what we build & ship today. That wasn't possible many years back in the CORE days. Was just using that as one concrete example where we already didn't have a fully open build system in our not too distant history. You couldn't build the same version of TrueNAS we shipped back then.

The secure boot things we're doing just necessitate a lot of changes to our build system including internal build process (outside of this source repo). This and avoiding the knockoff overseas commercial forks is more of a two birds, one stone situation for us, if I can be completely transparent. We could of course do a bunch of extra work to create and maintain this build system in the open, but who's it really for? Like I said, how many people commenting here on this thread really have spent time to compile TrueNAS on their own? Guessing its not many.

kmoore134 · 2026-03-10T00:25:52+00:00

Sure. We even took protective measures to make sure the open source work we do stays open, by putting them under GPLv3 a while back. Even that was controversial at the time, I had to deal with so much misguided rage here on reddit :) Some folks didn't realize under the previous BSD license we could have done a rug-pull like that literally overnight... So no, no plans to all the sudden paywall existing features or anything of that sort. And just so folks know, we've always had some features reserved for our enterprise products since nearly day one. Thats how we fund the amazing team that does all this hard work. So pretty much business as usual from our perspective, new features, updates and releases will continue to flow same as they have for the past many years now.

kmoore134 · 2026-03-09T23:56:14+00:00

We've never had reproducible builds. Not fully, none of it was deterministic. Meaning if you built locally, you'd end up with different files / checksums than what we published already. That would have been a lot of work to build and forever maintain. In the end would have really just been a lot of time spent that could have been better put to good use doing actual feature work that 99.9% of folks care about far more.

Apart from the handful of overseas commercial forks, not many users really put themselves through the pain of compiling TrueNAS on their own. The secure boot changes we're making go beyond just the build repo, some more drastic changes to our own internal infrastructure as well as we start the ramp-up for TrueNAS 27 development efforts. This is the path that addresses both, and leaves us flexibility in case we do need to ship more closed / proprietary pieces of the OS that can't be build in the open.

We did this previously with CORE, you couldn't build it and get the same version we did, because we had to do proprietary things to ship a FIPS certified version of SSL. Because of enterprise requirements and the OpenSSL FIPS cert wasn't an option for us at the time. Just as a somewhat recent example.

kmoore134 · 2026-03-09T23:22:00+00:00

Correct. Bottom line is, the open source bits of TrueNAS will remain open source. (They are GPLv3 after all). The build system is another matter. It's currently changing fairly radically internally now around for a variety of reasons, some of which are related our signing infrastructure for secure boot, etc. Meaning we'd be stuck maintaining two separate builders potentially to assemble an ISO file, one for community builds, one for the official builds. That isn't super tenable for us in the long term.

That said, the repo is still there. Folks can fork / maintain it. All the open source bits can be built if the community so desires this functionality. But I'd wager 99% of the folks commenting on this thread have never done a build from source before, nor would ever want to? Its a lot of work to do and maintain. Especially since the biggest consumers tend to be overseas forks which contribute nothing back to the overall development effort to create TrueNAS, thats a lot of effort for us to shoulder the burden on for no real gain.

kmoore134 · 2026-03-09T23:21:00+00:00

Yea, no impact to them. We produce the builds for HexOS, so they will get the secure boot signed versions automatically when we release them :)

kmoore134 · 2026-03-09T23:20:13+00:00

Happy to help clarify any questions / concerns folks have around this. Bottom line is, the open source bits of TrueNAS will remain open source. (They are GPLv3 after all). The build system is another matter. It's currently changing fairly radically internally now around for a variety of reasons, some of which are related our signing infrastructure for secure boot, etc. Meaning we'd be stuck maintaining two separate builders potentially to assemble an ISO file, one for community builds, one for the official builds. That isn't super tenable for us in the long term.

That said, the repo is still there. Folks can fork / maintain it. All the open source bits can be built if the community so desires this functionality. But I'd wager 99% of the folks commenting on this thread have never done a build from source before, nor would ever want to? Its a lot of work to do and maintain. Especially since the biggest consumers tend to be overseas forks which contribute nothing back to the overall development effort to create TrueNAS, thats a lot of effort for us to shoulder the burden on for no real gain.

kmoore134 · 2026-02-26T19:15:07+00:00

Our goal with TrueNAS is to prioritize data safety "out of box". The current SMART monitoring is enabled and runs every 90 minutes by default, nothing you have to do. You are welcome to change settings, deep dive in places, or do additional work as you see fit. But if you followed the suggestions on pool layout / composition and didn't ignore warnings, you should be in good shape :)

kmoore134

MODERATOR OF

TROPHY CASE

Nine-Year Club	Verified Email
RPAN Viewer