One product, from the drawing to the audit log.

Apelora Fabric has two screens and one control plane. Studio is where you design; Fabric Console is where you operate. Every result here says how it was checked. How it compares with Proxmox VE, VMware and Kubernetes.

Design

Apelora Studio is a canvas for connected modules. Ports are typed, so a cable that cannot work is refused.

A catalog of 143 modules in 9 categories, and modules you define yourself.
Import and export designs as files; undo and redo.
Deploys today: NGINX (an application container), Debian (a system container) and a Linux virtual machine. The other 80 modules are design-only until their images have run on the lab.

Checked in a real browser

Apelora Studio canvas: a gateway connects to a load balancer, which connects to two NGINX modules and on to a PostgreSQL database; a Grafana module reads from the database. Cables carry protocol labels such as http and postgres. — A design on the canvas. Detail of a Studio screen, sample data.

Plan and deploy

Before anything changes, Fabric shows what would be created, resized or removed, and whether it fits your servers.

Containers and virtual machines, one per replica, with CPU and memory limits.
Volumes that outlive their instance: grow online, snapshot, back up to another pool, restore.
Resize running instances in place, and move an instance to another server (virtual machines move live).

Real Incus tested

Apelora Studio showing a capacity check: the design fits on one server, with the vCPU, memory and volume space it asks for next to what is free, and the three servers listed. — The capacity check: what the design asks for, next to what is free. Sample data.

Connect

Cables become network policy. Each application gets its own network, and only the connections you drew are allowed.

Deny by default, with an access rule for each cable.
Service addresses with health checks; a gateway connection publishes a module.
Each module is told its providers' addresses. Internet access is optional, per module.

Real Incus testedService names (DNS): roadmap

A design with a gateway, a web module with three replicas and a database with a volume, and the instances it becomes on three servers behind one service address. — Illustration, not a screenshot: a design and the instances and network it becomes. Select it to open full size.

Recover

Failed replicas are restarted or replaced. For a module that keeps data, Fabric fences first, then restarts.

Fenced means proven stopped: its storage lease is dead, its power is confirmed off, or a person confirms it. Two servers never write the same disk.
A container with data ran again 144 to 155 seconds after a forced stop, in three lab drills.
A server cut off but still running was switched off through its management controller and fenced after 61 seconds in the lab. That does not make the restart faster on this storage.

Real Incus testedRedfish: tested against a test serverVirtual machines: roadmap

Illustration, not a screenshot and not a measurement: the animation is faster than a real recovery. In the lab, a container with data ran again 144 to 155 seconds after its server was force-stopped. Virtual machines are not drilled yet.

Operate

Fabric Console, in your browser.

Servers, maintenance with evacuation, joining and removing servers, and cluster settings with a dry-run review.
Instances with logs and terminals; operations you can retry or cancel; networks and storage.
Applications start, restart and stop in dependency order, with a warning when clients would lose service.

Real Incus testedTerminals: checked against a stand-in

Fabric Console, Servers, Upgrades tab: members run two different Incus releases, a warning says to wait before upgrading because one server is offline, and a numbered rolling-upgrade procedure follows. — The Upgrades tab warns before a rolling upgrade and lists the steps. Sample data.

Secure

Access is explicit, and every change is recorded.

OpenID Connect, LDAP and local sign-in; roles at organisation, project and application scope.
A second person approves sensitive changes. A token can never grant more than its creator holds.
An append-only audit log, searchable and exportable. Credentials stay in the backend, never in the browser.

Checked with test identity serversNot independently audited

Fabric Console, Sign-in settings: three identity providers with their status, a local accounts switch, a directory section and an API tokens section. — Identity providers, local accounts, directories and API tokens. Sample data.

Monitor

Know before your users do.

16 built-in alert rules (failed jobs, silent workers, offline servers, expiring certificates, failed backups) with signed webhooks.
A metrics endpoint for the control plane and the worker, for your own monitoring.
A support bundle with versions, health and failed jobs; secrets are never included.

Checked against stand-ins and a real database

Fabric Console on a phone: the Servers page with its tabs and a member list. — The Console works on a phone. Sample data.

Roadmap: what is not built, or not yet tested.

We would rather tell you now. Each item is in the repository's status document with its current state.

Item	State	What it means for you
Production use	Not yet	Tested on a four-server lab of virtual machines; no real servers have run it, and speed and scale are unmeasured.
Virtual machines after a server dies	Lab-tested	On the lab, a virtual machine with its disks on shared storage was running again 141–144 seconds after its server was stopped, three times, and the file written beforehand was still there. The restart is a cold start. This was nested virtual machines, not a physical server.
Operating systems through MAAS	Not built	Discovery and registration of MAAS machines is built and tested against a real MAAS; installing an OS through it is not. Servers installed by hand join with a token.
Management controllers	Partly built	Redfish and IPMI can switch a failed server off and read that it is off. Both were tried against test controllers only, not a real server's controller.
More deployable modules	Ongoing	Seven of 143 modules deploy; each new runtime is added after its images have run on the lab.
Rebalancing and staged upgrades	Not built	Instances are not moved automatically for balance; the rolling Incus upgrade is a written procedure, not an assistant.
Service names (DNS)	Not built	Modules find each other through addresses injected as settings.
Several sites and regions	Designed	A design from three servers to a global fabric is written down; the multi-site parts are not built.
Remote desktop sessions	Not built	Terminal sessions exist; remote desktop does not.

The repository's status document is the source of truth; this page is a snapshot of it.

Words used on this site.

Module: A building block on the canvas, such as a web server or a database, with typed ports.
Instance: A running container or virtual machine that a module becomes. A module with three replicas becomes three instances.
Incus: The open-source system that runs containers and virtual machines across a cluster of servers. Fabric builds on it and does not replace it.
Fenced: A failed server is proven stopped, so it cannot write to shared storage while its modules restart elsewhere.
Replica: One of several identical copies of a module, run on different servers.
Runbook: A written procedure for a situation such as a failed server, with each step marked as tested or not.

Tell us about your environment

How many servers, what storage and network, who needs access. We will tell you what Apelora does for that today and what it does not.

Request a demo Ask about deployment