What teams use Apelora Fabric for.

Five scenarios the current implementation supports. Each one says what was verified and what is not in place yet.

Put a web tier on your own servers

Draw a gateway and web modules, connect them, and let Fabric run replicas on different servers behind one address.

What you do: Design in Studio, review the plan, deploy. Fabric creates the instances, the application's network, the access rules and a service address that the gateway publishes.
Verified: Real Incus tested on the lab: replicas on different servers, enforced connections, a service address with health checks, and the restart of a crashed replica.
Not yet: Seven catalog modules can be deployed today, NGINX among them; the others can be designed but not deployed. Nothing has run on production servers.

Put a stateful module on shared storage so it can restart on another server, without two servers ever writing the same disk.

What you do: Choose "shared pool" for the module's data in Studio. When its server fails, the Console shows why it waits and when it is fenced; the restart follows.
Verified: Real Incus tested: a container with a volume ran again 144 to 155 seconds after its server was force-stopped, data intact, in three drills. A server cut off but still running was switched off through a lab stand-in for a management controller and fenced after 61 seconds.
Not yet: Virtual machines are not drilled. The Redfish controller provider has only met a test server. The shared storage in the lab is a clustered volume group on a virtual SAN, not real storage hardware.

Add servers deliberately, give people only the access they need, and keep a record of every change.

What you do: Register a server, approve it to get a single-use join token, run the enrolment script, then admit it after its checks pass. Assign roles per organisation, project or application. Evacuate a server before maintenance.
Verified: Real Incus tested for joining, admitting, evacuating and removing servers. Roles, approvals and the audit log are tested with a real database and checked in a browser against test identity servers.
Not yet: Not independently audited. Installing the operating system on a new server is yours to do; the MAAS part of that is on the roadmap.

Serve images from your own mirrors and verify releases offline.

What you do: Name your image mirrors; Fabric can refuse any image that is not served by one of them. Install from a signed release bundle and check its signature before use.
Verified: Checked against local test servers and in unit and API tests, and signed bundles verified with the standard SSH signature tool.
Not yet: Not run on the lab with outbound traffic blocked. Treat this as designed and tested in parts, not proven end to end.

A lab of virtual machines stands in for servers, a SAN and, if you want it, a provisioning system.

What you do: Run one script to start a disposable Incus cluster in virtual machines, point the control plane at it, and use Studio and the Console as you would on servers.
Verified: Everything labelled "real Incus tested" on this site ran on exactly this lab. The guide says what the lab proves and what only real hardware can.
Not yet: The lab says nothing about real management controllers, network switches, disk speed or hardware faults.

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