Jump to content

jonp

Administrators
  • Posts

    634
  • Joined

  • Last visited

  • Days Won

    160

Everything posted by jonp

  1. Yes most definitely! We have the underpinnings for a language selector already in place, but we're deferring translation work until after 1.0.
  2. As of today, yes, you can access your server from anywhere using deck.hexos.com. I have a discussion planned with the team to allow you to disable remote access which would be as simple as us verifying the WAN IP of the client device being used to connect to the deck and making sure it matches the server's WAN IP. When HexOS Local arrives, you will be able to even further reduce your cloud dependency, but there are some features like installing apps/VMs, configuring buddy backups, and e-mail notifications that will require a connection to our deck. Thankfully that connection is outbound from your server, which doesn't require you to open any ports on your firewall and expose the system to the wider net. We also do have plans to implement oAuth and 2FA in the future to further enhance security and options.
  3. Absolutely. That is 100% doable.
  4. We know about this problem all-too-well. The VM features will come in layers, but our plan is to try and get ahead of those kinds of problems by detecting hardware changes and automatically adjusting device ID mappings to your VMs before they start. This still needs a lot of R&D work and there are lots of potential gotchas, but I bet we can address a lot of common scenarios like what you've described. It gets more tricky when you have multiple GPUs in a system of the same make/model, as it's hard to know which one is which for assignment to VMs. I'd say that's a problem for after the initial VMs feature release for us to investigate further. Ultimately there will be some limits to what we can do, but we're going to do this as best as is humanly possible.
  5. Correct. The additional licenses is for users that want to setup multiple systems of their own, not for buddy backups. @Todd Miller rightly called this out as confusing. What I meant to say is that you just can't transfer the license to another user. You can use buddy backups (as a feature) between two systems that you own and control (licensed under one account). Sorry for the confusion! Carry on!
  6. It's hard to believe it's already been a year since we launched the HexOS Beta and the early access campaign. What a journey it's been! In today's blog post, we're going to provide a summary of this past year's accomplishments, a run-down of what's left to achieve our 1.0 release, what's coming next, an update on the AnyRaid project, and our HexOS Holiday Sale! Read all about it in our latest blog post: https://docs.hexos.com/blog/2025-11-26.html
  7. To celebrate the holidays and thank our community for their continued support, we're excited to announce our HexOS Holiday Sale, starting today! Existing customers can purchase additional licenses for just $99 each, perfect for expanding your home server setup. New customers can take advantage of our special two-pack bundle for $298, with additional licenses available at the same $99 promotional price. Single licenses remain available at $199 until our 1.0 release in Q1 2026. This holiday pricing for additional licenses and the two-pack bundle is available through December 31st, so don't miss out on this opportunity to join or expand your HexOS experience. Please note: License transfers are not permitted. All licenses are tied to the purchasing account. Buy now from the HexOS Store!
  8. Def not cloud only. If your isp/network supports peer to peer, we can coordinate that and then get out of the way. That is what's included in a lifetime license. If we end up having to relay traffic for some users, that will require a subscription as we will have to pay for the relay traffic, but obviously it will still be encrypted.
  9. My fault. I dropped the ball on this one. I'll circle back to it next week to make sure we get it addressed. I know you aren't the only RSS user out there 😉
  10. If there are still a plethora of users affected after Local is released, we would consider it. But if not, we would rather spend the time via support helping people up over this fence than engineer an entire solution for a handful of folks. Support@hexos.com is available to you at no cost.
  11. If you guys are stuck, please email support@hexos.com and we will schedule a time to work with you on this.
  12. 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.
  13. 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.
  14. 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.
  15. Yup it was added last night! Check the original post for instructions.
  16. Thanks for reporting these issues. We are taking this feedback to heart and will work to address.
  17. 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.
  18. @mill3000 can you help this guy out? Thanks!
  19. We moved the blog to the docs site. I'll chat with @csmanel about getting RSS support for it.
  20. You nailed it! We are loving playwright.
  21. 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.
  22. 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!
  23. 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!!
  24. 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.
  25. @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?
×
×
  • Create New...