Rust at the core
Suite services written for speed, safety, and maintainability—software you can own for the long haul.
What we assemble and ship
Technology & infrastructure
How we build commercial on-premises systems: proven open platforms, disciplined engineering, and hardware we can assemble, ship, and support—without locking you into a rented control plane.
Linux hosts
Rust services
On-prem ready
You operate it
Platform stack we ship with
A clear commercial technology posture—open foundations we know deeply, combined with hardware build experience for real sites.
Incus containers & VMs
Modern system containers and virtual machines for clean service isolation on customer sites.
Ubuntu on servers
Stable Ubuntu LTS for servers and many containers — predictable operations and broad hardware support.
Linux on clients
Workstations we actually ship: Ubuntu Desktop, Linux Mint, or NixOS. Choose the one the operators will live with. NixOS when you want configuration-as-code; Mint or Ubuntu when the office wants a familiar desktop.
Lightweight edge Linux
Compact Linux profiles for IoT and field units—fast to image, easy to maintain, ready for constrained hardware.
Hardware we build & ship
From preferred Linux OS images to assembled clients and servers—specified, tested, and delivered for commercial environments.
Exact images and topologies are chosen per site. We share the stack principles openly; site-specific designs stay under NDA when required.
Why Rust, and why this stack
We pick tools we can still operate in ten years. Speed matters. Memory safety matters more when the box sits on a customer LAN.
Rust at the suite core
Saga, Aella proxy, Skjal, Skarð, and the site itself are Rust. No GC pauses in the hot path, no use-after-free class of C bugs, and a compiler that refuses a large set of mistakes before they reach a customer site.
Against the usual alternatives
Go is excellent for many network services; we still choose Rust where we want the type system to own memory. C and C++ remain in kernels and drivers, not in our suite daemons. Node and Python are fine for glue — they are not what we put on the trust boundary.
You can keep it
A Rust binary plus SQL is something an operator can back up, hash, and place on Incus. That is a better long-term story than a rented multi-tenant runtime.
Languages we write
Public, ordinary names. This is not an inventory of every library on the machines.
- Rust — Suite services, Aella proxy, Skjal, Skarð, marketing site.
- Python — Operator scripts, content export, install helpers — not the trust boundary.
- JavaScript — Browser consoles (Stella, Skjal, shop, playground). Lean HTML/CSS, no tracker SDKs.
- SQL (PostgreSQL / MySQL) — Edda is Saga’s Postgres. This marketing site stores contacts and translations in MySQL.
Open components we name
These are public foundations. Linking them is not a risk. Naming every model, voice engine, and internal worker would be.
- Incus — System containers and VMs on the site.
- Ubuntu · Linux Mint · NixOS — Server and workstation Linux we support.
- PostgreSQL — Edda — Saga’s database.
- OpenSSL — Certificates, TLS, and the playground decoder.
We do not publish the on-site speech, vision, or model list on this page. That stack is chosen per site and belongs in the deployment notes, not in a brochure an attacker can scrape.
Infrastructure & hardware
We design, specify, and can assemble and ship Linux clients and servers for commercial sites—edge boxes to rack systems—on the distributions that fit your environment. Office environment upgrades, networking, and commercial IT repair sit alongside the suite platforms we deliver.
Software core
Suite services are built primarily in Rust for performance, auditability, and long-term ownership. Clear APIs and suite sign-in patterns you can operate and reason about on your own network.
Operator interfaces
Lean HTML, CSS, and JavaScript consoles—no heavy framework lock-in, no third-party trackers. Built to stay usable on restricted and air-gapped sites.
How we deliver
In-house engineering practice accelerates design and review so we can ship production systems faster. Delivery tools are how we work—not a product you are forced to buy.
Your runtime, your site
We minimise opaque third-party runtimes. Dependencies are pinned and reviewable. The running system is software on your infrastructure, behind your network controls.
Typical site roles
A full site often separates org console, AI compute, operator access, fleet monitoring, and archive storage. Smaller deployments can combine roles on shared hardware without changing the product model.
Saga, Rune, Edda, public web, and Skjal — the human entry surface for the site.
Aella runtime: models, agents, jobs, and short-term operational memory for the AI product.
Stella — the operator console for Aella. Not every desk.
Thala server monitoring and remediation. Separate recommended product.
Long-term media, backup archives, and durable knowledge stores for the site.