Introducing Hye Ararat: A Web UI native to Incus

Howdy everyone,

I’m excited to share that the first public beta of Hye Ararat, a new web interface purpose-built for Incus, is now available.

Hye Ararat provides a clean, intuitive dashboard for managing your Incus deployment, and is designed to maintain the power tools one building a hyperscaler would need, while maintaining a low enough learning curve for someone running an iMac in their closet (my dad) to operate.

Too often, these clients just dump API data into a complex interface that is difficult to digest, or hide options for the sake of simplification. Ararat is built from the principle that a UI that services the needs of every type of member of this community can be built, if enough thought and effort is put into the primitives.

The most beautiful benefit about a web interface vs. a CLI, is that the way information is displayed can be completely specific to what you’re looking at and what you need. I can’t help but feel that the core principles of UI and UX, and the mission of building a path for anyone of any background to be able to access Incus, was lost in the current implementation.

Today, I’m thrilled to introduce the first beta release of this new interface. Currently, beyond the necessary core (authentication, communication, etc.) it contains almost complete implementations for:

  • Instances
  • Operations
  • Projects

Development on the remaining primitives will begin shortly, however, I believe the best path forward is building this with the community. The community-driven nature of Incus’s development is what has kept Incus strong, ahead of the curve, and always able to service its users needs. The web interface would benefit so much given the same community-driven environment, so if the interest is there, I would love for this post to be the catalyst towards building that future.

I’ve set a roadmap with full coverage with the other primitives for July 24th. The decisions made at this early stage are the ones that last the longest, and this is the time in which they are the easiest to change. I would much rather make those decisions with the community than in front of it.

So please, try it, break it, complain about it, tell us what you hate, tell us what you like, tell us what feels wrong, tell us what feels right. Your feedback is the most valuable signal to where this is going to go. Everything is fair game, and all feedback will help build this to better serve the community.

Here’s the GitHub Repository:

Some screenshots (we love visuals! :slight_smile:):

12 Likes

I’d recommend creating pretty frequent tags as new features and changes land, then using a Github Action to automatically build the UI, create a release and attach the UI build as an artifact of the release.

That way you can easily publish instructions to go to Releases · hyecompany/ararat-web · GitHub to get the latest release or even directly link to something like https://github.com/hyecompany/ararat-web/releases/latest/download/ui.tar.gz to grab the latest build of the UI which they can just dump in place on their system to try out (Zabbly package users can put that in /opt/incus/ui, users of other packages can put it anywhere they want so long as INCUS_UI is set in the incusd environment to point to that path).

This should make it a lot easier for folks to start playing with it and give you feedback even if they’re not comfortable with building a webapp locally.

4 Likes

I think this is a great idea to significantly simply installation & access.

I currently have a beta “release” schedule for about once a week (Milestones · hyecompany/ararat-web · GitHub). I’m thinking of auto-building every push to the main branch (this way people can easily install the most bleeding-edge), but then also attach pre-built archives to the releases on the schedule, as you suggested.

I’m currently locally working on implementing a fully-custom high performance SPICE client (all existing public implementations are GPL, which is incompatible with our license, plus, they aren’t very high-performance. I want the user to feel like they don’t need a solution like RDP. This helps with with our established goal of something suitable for every user, and Incus being the all-in-one solution). Since a lot of its’ logic is written in Rust (which compiles to WASM), the build pipeline will be different once the SPICE client is pushed (deadline is Beta 2, which is May 1st). I’ll add the pipeline as soon as the SPICE client is added.

1 Like

@Hye-Dev Just passing it along since you mentioned Rust. A good friend of mine created this repo a couple of days ago. Hope its of some use to you. GitHub - nandushankar/py2rust: Python to Rust converter · GitHub

@Student most of the SPICE logic is focused on getting from message → draw as fast as possible, so this component specifically benefits from as minimal abstraction as possible, however, I’m sure that project is great for people who don’t know Rust who want to build things that have extreme performance constraints!

1 Like

Just so other people don’t have to spend time looking at this: it is a 326-line Python script (excluding the sample code) which walks the Python AST and spits out “rust equivalents” for each tree node. It assumes that Python and Rust are just different syntaxes to the same underlying programming model. In other words, it completely ignores the completely different semantics.

A fun toy, but not useful for any real-world applications.

1 Like