jonp

Hmm... @mill3000 can you connect with him on this issue?

Yup, this was addressed a while back. We do allow 1 drive pool creations now with a warning about no protection from data loss.

Yup. Unfortunately one of the packages that HexOS local depends on (bun) requires these CPU features (for now at least).

Question for any of you affected by this issue, are you running HexOS in a VM or on a really old CPU? HexOS Local, which is now a requirement of HexOS, requires the AVX and SSE4.2 instruction set on your processor to function. Pretty much all modern CPUs released since 2011 have these instruction sets (there may be a few outliers that I'm unaware of), so either you are all running on really really old hardware, or you're running in a VM that is not exposing those instruction sets with the CPU model. If a VM, you can change the CPU model to "host-passthrough" or simply something that supports these instruction sets.

We have no editorial input or control over the LTT videos. We don't pay for sponsorship or anything like that either. The fact that it came out this weekend was pure happenschance. We are looking into the SMB issue and will see what we can do from our side to address. Tbh, what we have planned for the rest of the year is going to have an even bigger impact than the 1.0 release in my mind. With respect to price, an announcement about our scheduling pricing changes will be coming soon.

@mill3000 let's take a look at his issue this week.

All we can say at this point is we are slowing rolling out local to new users. Over 400 so far have been migrated.

I did say BY end of April ;-). Truth is we have been pretty much right there aside from a few issues, but the big one was the availability of HexOS Local. But we decided yesterday that we can still call this 1.0 and roll out Local to everyone over time. The local project has to be rolled out more slowly as we have SSL cert issuance limits right now.

https://docs.hexos.com/blog/2026-04-02.html

https://docs.hexos.com/blog/2026-04-02.html

I appreciate the understanding. I'm actually in the process of approving the post right now. Had a full day packed so it had to wait until tonight.

I'm out of town right now but let me just state that I totally get the folks that are upset. Honestly, writing blogs is pretty stressful for me as we constantly are working on moving targets and I stress over communicating about things that are still in flux and getting the words right. Tbh, I stress over comms in general. It's nerve wrecking. It's why I am earmarking funds this year to bring someone in to handle this for us. I just didn't want to spend any money on non dev/support resources until we got to 1.0. Again, I get it and I am not gonna make any excuses for it, so if you want to be mad, please direct that anger at me, not my team. They are busting their butts to get this thing polished and rolled out.

This one is entirely on me. I am traveling today but I will be working on getting this blog post up tomorrow (April 2nd). I'm also planning to hire someone to take over marketing/comms this year as a full time position.

Working on a blog post with an update. We had to push back to April due to some issues with our health system that we've been tracking down since February. The plan is to both begin the rollout of HexOS Local and complete the health system upgrades and then release 1.0 by end of April. I was hoping to get a blog up today with all of this information, but it just didn't come together fast enough.

At this point, just using HexOS to create folders, users, install apps, etc. just like normal. Use it both locally and remotely. That's really it. At this point, the main thing we're testing is that it works correctly, navigating you to the local interface when on LAN, and giving you remote access via the deck when away. If you can break your system (non-critical data only), there are a few specific cases we would like to see users test like destroying the pool used by apps (Docker) manually via TrueNAS, then renavigate to deck.hexos.com to see if you can remediate the issue. Obviously not asking anyone with real data on their systems to do this, but for those that have test setups, just beat the heck out it and see what breaks. We test internally pretty rigorously, but there's always edge cases that we can miss and this is the chance to find those as best we can.