jonp

If you guys are stuck, please email support@hexos.com and we will schedule a time to work with you on this.

It did. We wanted to build in a better solution to address this, but as I stated in the OP, it would have required a massive divergence of focus from our team to build a solution within the UI itself. We ultimately decided putting out this post and offering 1:1 assistance to those affected was the best course of action. We are offering 1:1 support to anyone that needs it. Just email support@hexos.com and we'll schedule a time. I mention in the OP our plans to be able to better address this in the future via HexOS Local.

That thought did occur to us, but to be perfectly honest we'd rather anyone not comfortable following the guides or having difficulty to just contact us directly for support. That's what you all paid for and we are gonna provide it. I don't want to start asking our users who aren't comfortable to navigate the TN interface.

Let's Talk About Immich If you've been running Immich on HexOS this year, you know it hasn't been smooth sailing exactly. We want to talk about what's happened, why it was so challenging, and how we're working to handle these situations better in the future. What Happened? Earlier this year, Immich deprecated their old storage configuration and required all users to migrate to a new structure. For users running Immich through docker-compose or other manual setups, this meant updating some configuration files and running a few commands. Annoying, but manageable. For some HexOS users, the migration was more involved. Because of how TrueNAS SCALE structures application storage, moving to the new configuration required either reinstalling Immich fresh (the simplest solution) or manually migrating existing data between datasets (a process that involved SSH access, rsync commands, and careful attention to permissions). But if you're choosing between "reinstall the app" or "follow a 15-step guide," neither option feels great when you chose HexOS specifically to avoid that kind of complexity. Why Was This So Hard? When Immich made this change, we had a choice to make. We could have built a comprehensive rsync-based migration tool using the TrueNAS API. It has those capabilities. But that would have meant dropping everything else we were working on to build what amounts to using a cannon to kill a mosquito: a massive, complex solution for what we hope won't be a regularly recurring problem with this particular app. Instead, our community stepped up in a huge way. Users like @forsaken and @G-M0N3Y-2503 created detailed guides (to move or rsync your data). These guides walked through the manual migration process to preserve existing data in Immich. They focused on helping users through the immediate problem, while we continue building the platform we need to handle situations like this properly. That platform is HexOS Local: a locally-hosted management application that will let us perform complex operations without being bottlenecked by the engineering overhead of building one-off solutions through the SCALE API every time an application throws us a curveball. This reduces the technical burden on our team and, more importantly, gives us the flexibility to automate maintenance tasks that previously would have required manual intervention or massive engineering investments. This same platform will serve the Local UI/UX feature we've committed to delivering as part of our 1.0 release. We'll be talking a lot more about HexOS Local in an upcoming blog post, but the key takeaway is this: we're building HexOS to handle whatever the open-source ecosystem throws at it, without having to choose between "drop everything and build a custom tool" or "make users SSH into their servers." What About Right Now? If you're currently running Immich on the old storage configuration and haven't migrated yet, you have options: The simple path: Reinstall Immich fresh with the new configuration. Your photos will need to be re-uploaded, but the setup is clean and straightforward. The preservation path: Follow one of the community migration guides to keep your existing data in place. These guides are more technical and require command-line access, but they work. Our recommendation depends on your situation. If you have a manageable photo library and good backups, the fresh install is probably your best bet. If you have years of photos, carefully organized albums, and user configurations you don't want to recreate, the migration guides are there for you. And if this seems to daunting, email support@hexos.com so we can schedule a time to assist you directly. Moving Forward The Immich situation showed us exactly where we need to invest engineering effort. We can't keep facing the choice between building massive one-off solutions or asking users to break out the terminal. That's not sustainable, and it's not the HexOS we're building. Immich is an incredible project. It's exactly the kind of self-hosted solution we want to make accessible to everyone. The team behind it recently released v2.0, marking their stable release with better upgrade paths going forward. We're committed to making sure that when the next complex maintenance task comes up, whether it's Immich or any other application, we have the infrastructure in place to handle it gracefully. That's the HexOS we're building. Thanks for your patience while we get there.

Yup it was added last night! Check the original post for instructions.

Thanks for reporting these issues. We are taking this feedback to heart and will work to address.

For the issue with immich right now, the guide is the best option. We are planning for a more elaborate way of addressing app issues like this that will put less burden on the user, but we have to build our own local app for that first.

@mill3000 can you help this guy out? Thanks!

We moved the blog to the docs site. I'll chat with @csmanel about getting RSS support for it.

You nailed it! We are loving playwright.

I fixed it that night. We migrated all the previous blog posts to the doc site as well as updated the link to it from the home page.

Kudos to the entire team for their hard work on this. Proper testing is a key component of our focus on delivering an excellent user experience and will continue to be integral to our mission. Great work to all involved!

One interesting thing is I was actually his software support contact behind the scenes (previous job) and helped him a lot with the multi seat gaming videos starting with 2 gamers 1 cpu but especially the 7 gamers one with the custom water block for the AMD cards. I had him setup remote access including a webcam that was pointed at all the monitors on the ground so I could see them light up for gpu pass through. Was a helluva project!!

This is actually something we intend to do using vfio stubbing if that's what you're referring to here. VMs are a 2026 objective for us.

@csmanel is in charge of our docs site and I agree, this could be a good addition. Cole? You mind taking a stab at that?

Settings > Locations is where this functionality will live but it doesn't have the ability to remap locations in use at this time (have to do it before you load them up) but will have that in the future! When you install an app that requires a folder for say media, we auto create those folders for you to use to store them in, but if you have already manually done that, we have to add the ability to the command deck to remap those (coming in the future). For now you could remap via the truenas UI but it requires a bit of handholding from a TrueNAS rockstar to know what you're doing in there 😉

If you've installed an app using the TN user interface, you're going to be managing that app through TN for controls for a while. Supporting migration from TN to HexOS managed apps is not on the roadmap right now, but may be in the future. That said, if you remove the app from TN (but not your user data), you can then install it from HexOS. You will have to reconfigure the app but the user data will remain intact.

Apps are running in docker containers. They install preferably to an SSD pool but will default to whatever you have if only HDDs are present (performance may be impacted depending on the applications storage performance requirements and other concurrent usage). The OS boot drive does not store the applications themselves or their configuration data. All of that is stored on one of your storage pools. The OS boot device stores the distribution itself and it's configuration settings. That's it. Apps do not run in full VMs. VMs would be useful for non-containerized applications (if you have any requirements for that) or non-Linux based workloads (e.g. Windows). Not necessary for Plex or Jellyfin Apps work similar to a VM from a control standpoint. You can start, stop, and update them independently from one another. And if an app goes completely haywire, removing it does NOT remove the associated user data (e.g. removing Plex/Jellyfin does not delete your content). Hope this helps!

This man devs! Not sure I could of said any of it better myself.

Hi there and welcome! What apps and services do you think you'll be running and how many users? What about total storage needs? Have you already purchased the gear or not quite yet? Depending on your specific needs, there may be options to go with that would be less power draw and less noise too. Not sure if that's a factor you want to consider.

Appreciate the criticism and we take it in stride. I respect everything you and others post, both good and bad. Sometimes raw emotional responses can cause gut check reactions of "you're kicking my baby" but I don't let myself see it that way. You're obviously passionate about our project or you wouldn't be here pointing out all the ways in which we can do better. I also respect not wanting a refund and I look forward to the day when I see a post from you saying, "ok, this was totally worth it and I'm glad I bought." 💯 Agreed. Our CTO has a proposal for us this quarter to do exactly what you're talking about. It's premature to share but know that we are on the same page and intend to do this. We intentionally built the global HexOS messaging system for this back with the Q2 release. We now want to expand that to include notifications for app-specific issues like this. But keep in mind that was not the original plan for 1.0 so the scope is no increasing, which is fine, but we still have other projects and objectives to hit, one of which is the Local UI which is a much bigger project than I think anyone realizes. It's complicated by the fact that our actual footprint on the ISO today is very small and we do not want to bake any of our UI into that ISO either. Instead, we have to build a full container/app for this which we are doing, but it's a huge project and we have a senior dev completely focused on it right now. I feel like a broken record saying this, but a big part of our struggles this year is bootstrapping the business. Money doesn't solve everything, but it sure as heck would have helped to hire a lot more developers and app specialists right at the beginning of this year, but we opted for a more fiscally conservative approach to hiring to ensure we don't grow too big too fast and make commitments to employees we can't keep without proving our business model first. Expansion is a big part of our plans for 2026 and will help us get more focused on individual layers of the software. Sure, but that comes with its own set of challenges and problems. Again, everything is still in flux and user data is not at risk. The worst anyone should have to deal with is reconfiguring immich from scratch which of course isn't ideal, but let's be honest here, it's also not the end of the world or an unrealistic expectation given the beta nature of both us and Immich itself. Comms of course could be better, always. But we are doing the best we can with what we have for now and we would just ask people to be patient while we work through it. This was all part and parcel of participating in the beta and if that's not going to work for anyone, waiting to deploy until more polish is applied would be the right approach. I've already spent hours reading and replying here and the more we try to get ahead on comms, the less time we spend on building and getting to a release. Every hour is a choice and often there are no options that will satisfy everyone. Still totally understand the frustrations, but this is the last I'll be commenting on this today so I can get back to work with the rest of the team. Our new docs site is a great place for us to put a guide for immich issues and resolving them in the future. Stay tuned for more, but know that we don't have the ability to always drop everything we are doing to shift focus to an issue like this when we are in the middle of other projects. There can be a lag time and that is something everyone here will have to accept while participating in the beta. Again, if that doesn't work for anyone, wait for the polish to come before deploying.

@mill3000 can you take care of this gentlemen's request? Thank you!

😞 I totally get this disappointment. I don't even blame you. We are targeting a more casual user and I can see how users like yourself may have had a higher expectation closer to that of a video game beta, where it's really software that's functionally complete, but just testing integrity of the infrastructure for multiplayer and game balance. You might find a bug or two, but nothing too crazy because part of the purpose of the beta is to build hype for the game prior to release, as we just saw with Battlefield 6 Open Beta. All of that said, we did say this was beta and listed out all the risks in the very first post you read to get it downloaded and installed. Furthermore, we actually had a second fix in for th migration issue for Q3 but due to another immich update, it broke again literally the day before the Q3 release and we missed it because QA was the week prior. This was just a very unfortunate coincidence. It seems like you specifically may be very frustrated with us and not happy with your experience. If you would like, I will refund your purchase. We don't want anyone feeling raw about their transaction, so if you want to take me up on that, feel free to drop me a DM. We are a small but growing team and will speak to our plans to get even better about this for post 1.0. We will be building an Apps team that will be responsible for ensuring our curations remain solid and that we handle these types of issues better. This analogy was spot on. Appreciate you taking the time to lay that all out.

To be fair, we actually did fix the issue referenced in that post. However, additional issues have crept up especially with the recent updates to Immich in preparation for their 2.0 release. One major change they made actually requires users to go through a migration process (a choice by the app developers). It's important to remember that Immich is a free-to-use self-hosted solution, which means that sometimes they may need to do things like this as opposed to the slick polish you'd see on a commercial product. That being said, we're still incredibly impressed with Immich and see it's future very bright.

We actually began the VM work last year but it started breaking as TrueNAS was making changes to the underlying stack. As such, VMs were delayed as a feature. 25.10 promises even more improvements to the VM stack and API so we aren't going to resume work on them until that is stabilized. In the meantime basic start and stop functionality exists in our command deck so if you create a VM in TrueNAS it will show up for basic controls in our UI.