Hye Ararat Beta 4 is now available

Hye-Dev · May 16, 2026, 12:55am

Howdy everyone,

Hye Ararat Beta 4 is now available. The release is available here: Release Hye Ararat v3.0.0 Beta 4 · hyecompany/ararat-web · GitHub

For context to those new: Ararat is a modern web interface native to Incus currently in development. You can learn more here: Introducing Hye Ararat: A Web UI native to Incus , and installation instructions are available on our GitHub.

In the Beta 3 announcement, I stated that Beta 4 would introduce storage pools as our first primitive beyond instances. After a community member did some experimentation with authorization and reported several issues, I found some large changes would need to be made to support that in the future. I decided that rather than pushing storage pools through now, it would be better to harden the foundation & delay storage pools to Beta 5. You can read more here: Hye Ararat Beta 3 is now available - #4 by Hye-Dev

Some new information: since Beta 5 will already present a large refactor, I’ve decided to also go after some other areas that have been on my mind. Most notably, Ararat will no longer be built on Next.JS, and will be moving to a Vite stack. This is more compatible with the SPA + client-side nature of Ararat. These changes are well underway on my local machine, and will be on the repo in the coming days.

Thank y’all for the continued testing & feedback! These decisions would have never been made without y’all. As I said in Ararat’s introduction post, the community-driven nature of Incus is what makes it the best, and it’s absolutely amazing to already see this transformation in Ararat at such an early stage.

These architectural changes are not present in this release and will debut in Beta 5 alongside storage pools. That being said, Beta 4 still made significant progress that warrants some announcement & excitement!

What’s New

New File Manager

The file manager now includes:

Dedicated search tool
Directory count
Persistent go to (ctrl/cmd + k as well!) / path copy actions

The file manager is now also significantly faster, taking advantage of the new caching system introduced in Beta 3 last week (see Hye Ararat Beta 3 is now available ). It also now actually informs you when a directory is empty, rather than just showing a generic blank screen! (groundbreaking I know!)

The file editor has also received various improvements, now featuring a theme consistent with the rest of the interface:

I also have expanded the syntax highlighting support, now also supporting C, C++, and Go.

Ararat also now automatically detects what files can be opened in the editor, and what must be downloaded by automatically inspecting the file for binary data before deciding to open. Any text files just open seamlessly, and everything else downloads straight to the disk.

New Instance Tab Design & View Transitions

The new caching system introduced in Beta 3 made data appear pretty much instantaneously, removing the display of a loading spinner most of the time.

Usually, a loading spinner serves as the natural transition between pages, however, after Beta 3, data just appeared immediately, which didn’t feel quite natural, so I’ve employed view transitions across the instance interface to bring back the natural fluid feel Ararat previous gave.

You can also see the instance tabs have been redesigned, they just didn’t feel quite right before. I hope y’all like them, these will be re-used across other primitives.

Additional Notable Changes

Instance logs have been moved to their own dedicated tab, rather than within the instance management dialog. The visual mode is also now properly virtualized, so a 20K line file will no longer lag out your computer!

Several of you reported a bug where Ararat reported that the “path” parameter was required, preventing the attachment of non-filesystem storage volumes. This has been fixed. You can now attach your non-filesystem volumes with no artificial blockers.

Hye-Dev · May 16, 2026, 3:57am

Side note:

I’m aware of some issues introduced by the data fetching layer re-write back in Beta 3. While this release did address some of those, there are still some present.

For example, the instance table may not properly detect its stale from the cache unless a change is made while Ararat is open, and CPU usage calculation always outputs 0%. These are all caching issues that will be addressed early-on in Beta 5’s development.

The reason I note this is data fetching is used literally everywhere, and Beta 5 is Ararat’s monthly “large” release, so it leaves the normal weekly cadence for a release date of May 24th, which is a little far out for something that can get pretty annoying.

Usually, I would merge the same fix for an issue like this from the bleeding edge into the active beta channel, however, since Beta 5 is structurally different, the fix does not overlap at all (the layer was effectively re-written again). Therefore, I recommend for the most stable experience, actually sticking to the bleeding edge builds until then. You can think of this as a using Windows Vista vs. Windows 7 Beta situation. Apologies!

Hye-Dev · May 24, 2026, 8:51am

Hey everyone,

Unfortunately, Beta 5 will not be launching today.

I’ve been hard at work on the refactor announced both here and on my response on Beta 3 Hye Ararat Beta 3 is now available - #4 by Hye-Dev . This included both a complete re-write of the Incus communication / caching layer (again!), and a transition of the entire stack from Next.js to Vite. These are fundamental structural changes, so these are much more carefully thought out, with much less AI involvement (next to none). This has been a much larger than originally anticipated endeavor, and in the process I have discovered a lot of technical debt that I feel the need to address (some of which arguably contributed by the aforementioned AI involvement, thinking we need some sort of policy on this, would love to talk about that). As a result, I am going to have to ask for your understanding in a divergence from our regular beta release cadence. I could absolutely just push through new features and primitives like the storage pools I have continuously promised (so sorry!) on the current foundation, however, the quality of the user experience comes first. To put it plainly, Ararat should have a foundation that lives up to its namesake, even if it comes at cost of velocity.

I am deeply sorry for establishing such unrealistic expectations in relation to Ararat’s velocity. It was my genuine belief and intention to deliver on the roadmap I outlined. The responsibility of establishing & communicating a realistic roadmap with the community lies with me. I can’t make any promises as to when Beta 5 will release, or what will be present within it. That being said, I can provide an update on where things stand.

Some technical details as to where progress as stands:

Things are on my local machine for now. This is just going to be several giant commits when done (e.g. movement to Vite + Data fetching is going to be one). I can’t really push incrementally on this one because it’s basically a re-write using the same components, everything has to be moved to work, and many shared areas have behavioral changes as a result of the new data fetching system. This is why the GitHub has been quiet.

Data Fetching

The new data fetching system is pretty much done. It’s now essentially a replica of the Incus database living in your browser, populated into memory for fast access with a write-back cache, automatically handling relations and intelligently inferring resource existence through any hints dropped by events or metadata (e.g., a used_by on a project fetch would immediately inform Ararat that those resources existed if it didn’t know). Beta 3’s was already extremely good at this sort of thing, but this new system knocks it out of the park. Sometimes, even the first load of a resource won’t even have a loading screen because of this smart inference! Feels like sorcery, not even exaggerating there.

Migration

The Vite migration is still in progress (the above is in Vite already!). Most of the technical debt discovered lies in the larger re-used individual components, like the general configurator. This work is almost complete. I am exploring whether or not I should PR some normalization now into Incus on some of the endpoints we use and write for those new structures, or keep the methods we currently use (which in some cases even resorts to hilariously clever description parsing) before finalizing. I think this will depend on how much of a pain this becomes when implementing future primitives. Community collaboration on that would yield really positive results. Migration of the base primitives themselves (e.g. projects, instances) has started, but is very early.

I’ve been having a little bit of a battle with, of all things, getting the view transitions to work properly. Next.js used React canary, so I could use the experimental view transitions API. I instinctively thought it better to use React stable, so I’ve been making my own lightweight view transitions adapter to handle this. Moving to React canary would make this a lot easier. I’m 50/50 on this decision. Would love community input.

In terms of migration, anything I didn’t mention has been a breeze to move, so wasn’t notable.

New Primitives/Features

There is no progress on new features or new primitives such as storage pools. All my efforts are focused on the foundation.

Establishing Future Expectations:

Some may question why all of the delay and turbulence in the development process for an “Incus UI”, seems pretty straightforward, right? That’s understandable on a surface level, but this generalization is exactly what Ararat seeks to challenge. Ararat is actually much more complex than meets the eye. As stated in its introduction post, I specifically designed it not to be a simple representation of the Incus API in Web UI form, but rather a fully fledged first class interface, feeling just as native to the browser as the CLI does to the terminal, for any user of any experience level to feel comfortable in. Ararat’s development process is not directly comparable to something like incus-ui-canonical, there’s a lot more engineering to it. You can see this already in the past few updates, building a SPICE client from scratch, bringing you graphical performance faster than you even thought was possible in the browser. Our normalized caching / data fetching system which keeps network traffic to your Incus host minimal, while also eliminating almost all loading screens & making the interface update live as changes happen on the server. Ararat even went as far as featuring automated binary file detection in the browser, just to make editing a little easier. Almost every single little detail I add, is implemented to this degree of thought in relation to the user experience, regardless of the level of effort or how small it seems. This is the reason why Ararat exists in the first place. I fell into the trap of planning deadlines & our roadmap around the velocity of building something with an API-wrapper degree of simplicity, when Ararat is uniquely “API-native” (if that’s a term). Going forwards I will be much better about this.

As for the original July 24th target for stable release with all primitives, I believe that this is still in the cards, provided there are no further surprise technical debt situations. I actually intentionally set that date with a 1 month buffer from what I anticipated.

I hope y’all will continue to provide feedback! This entire refactor started from one message from a single community member. I hope that makes it clear without a doubt, that your voice has huge impact.

Daniel1 · May 25, 2026, 11:36am

I would like to thank you for an update and your effort with developing Hye Ararat project. I believe modern UI is a missing piece of the entire Incus stack. Since Stephane and the Team are focused mostly on functional level of the project, UI and worklow orchestration was missed from my perspective. To be considered as alternative to other hypervisors for masses, Incus must have user friendly, properly designed UI. This is already happening for Proxmox (PegaProx or Proxcenter) and it was a core for VMware success.

From my perspective you should take as much time as possible to develop well designed, fast and secure product. I really appreciate your updates on Incus community forum.

The only part I’m worried about is that Hye Ararat is a single person project (at least for now). If you will lose your energy or passion with developing it, there will be no one else who will support it. Take a look on LXConsole project. This is a great tool but updated very rarely in recent months. Unfortunately I’m not a developer so I cannot participate with developing Hye Ararat, but to let you know I really appreciate your work on this.

turtle0x1 · May 25, 2026, 6:05pm

Most great ideas start as one persons passion - “1 dev” - its not a reason to write it off, ever.

The only UI with > 1 regular dev im aware of is lxd-ui, and I suspect that’s only supported by cash from unrelated sources - not buy support contracts for LXD directly (maybe its directly funded, but I have my doubts).

Cash/crypto > contribution > helpful feedback > literally anything else > “why only 1 dev" comments

Estimates are the hardest part of software dev - with or without AI - good luck on the next release.

Hye-Dev · May 26, 2026, 1:31pm

@Daniel1 Completely agree on every point, and appreciate the kind words!

On the solo development aspect, I also completely agree, and this is the reason why I actually don’t want Ararat to be driven by me. Ararat should be driven by this community, ideally with governance by Incus leaders & myself. Close collaboration would definitely make this much more apart of the “stack”. I also believe this approach is what would differentiate Ararat’s lifespan (for lack of a better word) from that of those which came before it. The passion driving the project would not be controlled by the flame of one (which is very bright! I love working on Ararat), but that of the entire community.

The most valuable contribution by far is feedback, and yours has given me a lot to think about in terms of governance & longevity

stgraber · May 26, 2026, 1:52pm

I’ve been watching all the progress and providing input where possible to try and steer it towards something we could turn into an official Incus UI.

So far it’s hit my main requirements:

Compatible license
Not based on the existing LXD UI (would be a licensing issue)
Limits hardcoded logic as much as possible, instead relies on data made available by the Incus daemon
Javascript-only client, no server component, Incus is the stateful server

My plan is to let @Hye-Dev keep pushing for end of July stable target, then have a discussion with the Incus maintainers on accepting it as the future “official” Incus UI, at which point we’d look at getting it fully integrated with the project, get more folks involved with development, figure out what needs to be implemented before we can start phasing out the LXD UI fork, …

So definitely something to look forward to in the coming months!

xlmnxp · June 1, 2026, 3:34am

I’m impressed by the progress you’ve made! I just replaced the Canonical UI with yours and everything works as expected, including OIDC!

It’s missing some features, but that’s expected for a Beta. Are there contribution guidelines and a roadmap available? I’d love to get involved!

Hye-Dev · June 1, 2026, 5:45am

Thank you! Glad to hear things are working as expected.

Unfortunately, contributing is a little complicated right now. There is an ongoing comprehensive local “re-write” (not sure what to call it) from Next.JS to Vite (hence the lower GitHub activity as of recent). This has morphed from much more than a stack transition, as in addition to a ton of underlying logic changes I posted about last week, I am also implementing a bunch of new enhancements into some of the existing components (eg. the configurable options selector now groups related options together to appear as “one” & features rich icons and descriptions). As the structure of the codebase will be completely different, I can’t currently merge any contributions.

Right now the contribution guidelines are pretty lax ( GitHub - hyecompany/ararat-web: Take your infrastructure to its peak · GitHub ), requiring just DCO sign-off, however, past AI-use did introduce some technical debt, so I am considering introducing rules around AI-use on contributions impacting core shared components/utilities when the new base is released.

Before the “re-write”, I utilized our GitHub milestones to outline a roadmap ( Milestones · hyecompany/ararat-web · GitHub ) and released on a regular cadence, however, this is now out of date because of the “re-write”. This will be updated when the new base is ready. That being said, I still fully expect Ararat to have a stable release with full primitive implementation towards the end of July. I don’t have an ETA just yet on when the new base will be published.

The changes I’ve made make implementing new primitives substantially easier, as much more of the logic is shared. Hopefully this will also make contributing much more straightforward!

jochumdev · June 18, 2026, 7:50am

A lot people seem to rely on a good Web UI, I see this as something important.

Hye-Dev · June 22, 2026, 4:29pm

TLDR: lots of really exciting stuff is on the way. July 24th is still the date. Re-write will be up in the next few weeks.

I thought I’d just provide an update on what the status of the re-write is for everyone! I’ve been getting a couple messages from people thinking things are abandoned. This is not the case! Just haven’t pushed since the codebase is currently a Frankenstein of unused Next.js logic for reference to migrate and isn’t at parity at all with the prior version. Expect a push in the next week or two .

Currently, the main slowdown has been that really nice “general configurator” component we have, which allows Ararat to display every single Incus config option in its UI natively.

Over the last several weeks I’ve been moving the component to use hard-written overrides instead of weird string parsing of the docs.

There are a couple reasons for this:

the objects I’m making could be used in the future to make the behavior of /1.0/metadata/configuration more approachable
I don’t want changes to the English in the docs breaking the UI in the future
There are now “access” functions associated with the configurable options (so it only shows options you have permission to see/change, and it now knows which options are dependent on one another (e.g., if you set restricted.containers.privileged to unprivileged on the project level, the UI won’t show options you aren’t allowed to set on the instance level.)
It can now display “warnings” instead of disabling options (e.g., if you haven’t enabled restrictions but enabled restriction settings, it’ll show a warning but still let you play with the settings, with a “fix” button)
More frequently used options come first
Groups have icons and descriptions
Things that are more “list like” can be like a checklist
AI doc summary is no longer really needed, since the configurator is so rich it replaces those docs for you!

There have been a lot of quality of life improvements I just added along the way you guys will notice & appreciate across all sorts of other components. The configurator is just getting the most attention since its so important .

The new configurator component is almost complete! After that there are a couple more major things that I want to update before publishing (have to move these components anyways, so might as well enhance them):

Migrating and re-writing the table component with the rich filtering I mentioned here Persistant settings in Incus UI? - #5 by Hye-Dev . Also have a bunch of optimizations related to table virtualization (already was really insane) that I’m thinking up that I wanna embed.
Gonna re-work the image “source” selector to display more information and be a bit more friendly.
VIEW TRANSITIONS MIGRATION (has been like a huge PITA, just gave up on that for now, going to have to go back and re-implement)
New Agentic Skills / AI Guidelines (ban on shared components, Incus doc traversal in addition to the API reference skill currently embedded).
Hover cards everywhere for resources/primitives, so you don’t have to navigate to a different page to know what something is.
Richer breadcrumb navigation on that top bar (e.g. fast instance switching)
New “Notification” system that can figure what what events the user is actually interested in watching live (e.g., I don’t need to see a “Showing console” if I didn’t launch the session in Ararat, and actually, that notification is annoying to even show…). Also show progress bars where we can.
The whole “Aside” component that takes over your screen is just obtrusive. Need to move to something that works like the sidebar but on the right.
Get those authorization changes in those components (thats what prompted this in the first place!)

Once that’s done, straight to storage pools, then the long-awaited Beta 5 will drop.

One may ask, with all that, how could all primitives POSSIBLY drop by July 24th? A big part of the architecture re-write was making it easier to wire to Incus. Ararat now has scripts that auto-generate types straight from the OpenAPI docs, a hooking system for the events and caching service, and a bunch of other stuff that makes adding primitives a piece of cake. That general configurator handles most of the hard stuff! Networks, storage pools, etc. are mostly just be frontend design work because of how easy wiring is with this new architecture .

So still expect full stable release by July 24th! All Incus primitives should be supported. I don’t see any blockers or slowdowns there. Maybe clustering might take me a little over-deadline to implement (I don’t currently have a cluster ready, and I develop on WSL so like yeah), or obscure things that require an environment to mess with, like CEPH. Additional authorization features coming soon to Incus ( Fine-Grained + Resource Authorization Handling on Incus API - #4 by bensmrs ) will be added right after the July 24th release, along with some of the other stuff discussed on this forum (like the graphical scriptlet editor).

Hope that helps everyone get a bearing on where Ararat is currently at and where this is heading.

Hye-Dev · July 3, 2026, 3:22am

There has been some serious blockage with the aforementioned new configuration component that will likely prevent the July 24th target. The re-documentation process of the configurable options is more extensive than the existing implementation, as well as the access control handling on the options themselves. This also delays the timeline of a variant of the re-write mature enough to push.

I know that there have been many blockers since I decided to move stack, however, I like to think of Ararat right now as going through what I would equate to the growing pains Windows went through in Vista to get to 7. The foundation being built will eventually bring out the best, even if it’s going to take just a while longer. The primitives are the easy part once we get there!

I’ll be making an announcement in a separate thread once I have a clear plan, also containing an update on where everything currently stands.

jochumdev · July 3, 2026, 10:19am

Thanks for telling, know this is free and open source, no hurry!

hihihihi that was a time

Hey if you want a private review or second opinion on anything please tell me (also via private messages).

Does Ararat provide an API for other clients?

Kind regards and good luck,
René

EDIT: I just read the post above again, seems OpenFGA would do the API?

Hye-Dev · July 3, 2026, 9:01pm

Thanks,

Ararat is fully client-side, so it does not expose an API. I am firm believer that all functionality should be contained within the Incus API itself, and if something isn’t possible that is needed, it would be better to change upstream rather than make a separate backend for Ararat.

While OpenFGA authorization is pretty straightforward to implement, Incus supports a variety of other methods, including scriptlets and restricted TLS clients, and Ararat needs to behave appropriately with those as well. A lot of people use projects to control access as well, so Ararat needs to behave well with those settings. The primary blockers related to authorization have been the scriptlets & project restrictions.

I’ve actually previously discussed a potential new endpoint to help remedy this here: Fine-Grained + Resource Authorization Handling on Incus API , and I think if we bundled some changes to how configurable options are handled alongside that, a lot of this overcomplicated stuff that is causing blockage would be remedied.

I think actually such an effort would generally be beneficial to the Incus community, as the documentation at-present of the various configurable options definitely need an overhaul, and going through each one is a lot of work. This is the perfect excuse to get it done, and I already have quite a head start there with the Ararat implementation as-is . I think the hardest part (beyond the deep dive into each existing option) is maintaining backwards-compatibility with the current definition methodology, because we wouldn’t want to break any already in progress PRs or functionality in clients that depend on the legacy system.