Xavi.app – Flexible Technical Platform Whitepaper (outdated)

Introduction

Xavi.app is a Canadian-owned AI infrastructure platform developed by TBI Contracting Inc. that provides high-performance compute resources for machine learning workloads xavi.app. Its mission is to let businesses and researchers train, fine-tune, and deploy large-scale models without the complexity of managing hardware or the prohibitive costs of hyperscale clouds xavi.app. The platform achieves this by combining open-source software components and efficient data-center design to create a flexible “AI cloud” – private, compliant, and hosted entirely in Canada. In essence, Xavi.app can serve as a secure, scalable backbone for AI, offering everything from raw GPU infrastructure to fully managed AI services. The following sections provide a high-level technical overview of Xavi.app’s architecture, core software stack, and key capabilities for delivering Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) solutions.

Core Open-Source Software Stack

A fundamental design principle of Xavi.app is the use of proven open-source technologies across the stack. This ensures transparency, interoperability, and ease of customization – qualities valued by both enterprise IT and government research. Table 1 summarizes the primary open-source components grouped by their roles in the platform:

Category	Key Open-Source Components
Virtualization	Libvirt (libvirtd daemon) and QEMU/KVM – virtualization hypervisor stack for VM creation and management.
Containerization	Podman (OCI container engine, Docker-compatible) – runs containers without a persistent daemon (supports rootless operation).
Networking	Netplan (with NetworkManager backend) – unified network configuration via simple YAML, enabling easy apply/revert of network settings.
Firewall	nftables – Linux kernel firewall (netfilter) framework, replacing iptables with atomic rule updates and improved performance developers.redhat.com.
Security	Fail2ban – intrusion prevention daemon that scans logs (SSH, etc.) and dynamically adds firewall rules to ban malicious IPS github.com/fail2ban.
Web Server	Nginx – high-performance web server and reverse proxy serving the portal and API endpoints. github.com/nginx.
Application Runtime	PHP 8.3 (PHP-FPM) – server-side language (running ConcreteCMS and backend services) via FastCGI process manager for efficiency.
Management Interface	Cockpit (with cockpit-machines & cockpit-podman modules) – web-based server administration console for managing VMs and containers cockpit-project.org.
Portal CMS	ConcreteCMS – open-source content management system for the user portal and web interface www.concretecms.com.
Database	MariaDB & phpMyAdmin – open-source Database management system for users, can be extended to support additional DB backends.
Communication	Matrix (e.g. Synapse server with Element client) – open federated chat protocol for secure, end-to-end encrypted messaging and collaboration element.io.

Table 1: Core open-source components in Xavi.app, by function.

Each component in the above stack is leveraged to deliver a cohesive platform. The virtualization and container engines form the compute substrate; networking and firewall tools secure and connect the environment; the web server, CMS, and Cockpit provide user-facing interfaces; and the Matrix protocol enables federated communication. All components are compatible with modern Linux systems and can be tailored or extended thanks to their open-source nature.

Operating System Compatibility and Deployment

To maximize flexibility, the Xavi.app platform is designed to run on all major Linux distributions. Ubuntu Server 24.04 LTS (code-named Noble Numbat) is the reference implementation and preferred host OS for Xavi.app due to its long-term support and widespread use. However, the software stack remains OS-agnostic and has been tested on or is readily compatible with:

Debian (stable releases and derivatives) – sharing a common base with Ubuntu.
Red Hat Enterprise Linux (RHEL) and clones like AlmaLinux – for integration into enterprise or HPC clusters standardized on the RHEL ecosystem.

By supporting Ubuntu, Debian, RHEL/AlmaLinux, and specialized variants, Xavi.app can be deployed in a variety of settings ranging from academic labs and cloud data centers to government installations with strict compliance requirements. All required components (libvirt, nftables, Cockpit, etc.) are available in the default repositories of these distributions, simplifying installation and maintenance across different Linux flavors.

Compute Virtualization and Containerization
(IaaS, PaaS, SaaS)

Xavi.app’s compute layer supports both full virtual machines and containerized workloads, enabling a hybrid approach that covers Infrastructure, Platform, and Software-as-a-Service use cases. The platform incorporates KVM/QEMU virtualization managed by libvirt, alongside container management via Podman (with Docker compatibility):

Virtual Machines with KVM/QEMU: Using KVM (Kernel-based Virtual Machine) and QEMU, Xavi.app can provision virtual machines that achieve near bare-metal performance by leveraging hardware virtualization extensions bdrsuite.com. The libvirt daemon (libvirtd) provides a unified API to orchestrate VM lifecycle and resource allocation bdrsuite.com. Administrators or automated tools can define VM images (for example, GPU-accelerated Ubuntu instances) and manage them through libvirt’s interface or via the Cockpit “Machines” module. This virtualization layer underpins the Infrastructure-as-a-Service (IaaS) capability, allowing delivery of isolated compute instances (VMs or even bare-metal allocation) to end-users.
Containers with Podman (Docker-compatible): For lightweight or microservice workloads, Xavi.app utilizes Podman as its container engine. Podman is a drop-in, open-source replacement for Docker that can run containers in rootless mode (no persistent daemon), offering security and flexibility blog.while-true-do.io. It supports the same OCI container images as Docker, meaning users can deploy applications using familiar Docker workflows. The Cockpit “Podman” module provides a web UI to create, manage, and monitor containers, making container operations accessible via browser. Containerization enables Platform-as-a-Service (PaaS) scenarios – for instance, Xavi.app can offer pre-configured container environments (with AI frameworks, libraries, etc.) that developers can build upon without managing the underlying OS. It also lays the groundwork for scaling out services via orchestrated containers or pods.

By supporting both VMs and containers concurrently, Xavi.app can offer a spectrum of cloud services from low-level infrastructure to high-level applications. In practice, this design allows the platform to present:

Infrastructure as a Service (IaaS): Deployment of raw compute instances – e.g. on-demand GPU virtual machines or dedicated bare-metal nodes – for users who need full control of an OS environment.
Platform as a Service (PaaS): Container-based platforms and toolkits – e.g. ready-to-use environments with pre-installed ML frameworks – so users can run code without worrying about system setup.
Software as a Service (SaaS): Fully managed AI solutions – e.g. one-click inference endpoints for popular large language models – where the platform handles the entire stack and the user simply consumes the AI service xavi.app.

This dual approach is a core strength of Xavi.app. For example, a research group could rent a GPU VM to train a custom model (IaaS), use the provided container images with optimized AI libraries for experimentation (PaaS), and then deploy a trained model as an endpoint service accessible via API (SaaS) – all within the same platform xavi.app. The open-source nature of libvirt and Podman also means these layers integrate well with external tools (e.g. Terraform for VM orchestration, or Kubernetes/OpenShift if scaling containers), protecting users from vendor lock-in.

Network Configuration and Firewall Management

Secure and flexible networking is critical in a multi-tenant AI compute environment. Xavi.app’s networking is managed through Netplan for configuration and nftables for the firewall, providing both ease-of-use and robust security:

Netplan with NetworkManager: The platform employs Netplan (Ubuntu’s unified network configuration tool) in conjunction with NetworkManager as the backend renderer. Administrators define network interfaces, IP subnets, VLANs, etc., in a simple declarative YAML file. This approach allows the entire network state to be reloaded or altered with a single command (e.g. netplan apply), which re-generates the system’s network config and applies changes atomically documentation.ubuntu.com. In practice, this means complex network changes (such as adding a new subnet for a VM cluster or changing VLAN tagging) can be rolled out without manually restarting services or disrupting other components. Netplan’s integration with NetworkManager also brings support for advanced features (like Wi-Fi, bonding, bridging) and an “auto-rollback” capability (netplan try) to recover from misconfigurations, which is valuable in remote or unattended deployments.
Firewall with nftables: Xavi.app uses nftables as the Linux kernel firewall for filtering and NAT, benefiting from improvements over the legacy iptables. Nftables introduces transactional rule updates, meaning firewall rulesets can be updated as a batch and applied atomically developers.redhat.com. This ensures that updates (e.g. opening a port or adjusting a VM’s security group) do not leave the system in an inconsistent state – all new rules take effect together, and if there’s an error the prior ruleset remains active. The nft command-line utility also allows the platform to load entire ruleset files, making firewall configuration stateful and version-controlled (important for auditing changes or quickly reverting to a known-good ruleset). In addition, nftables unifies IPv4, IPv6, and Ethernet filtering under one tool, simplifying the maintenance of dual-stack networks common in modern data centers developers.redhat.com.
Intrusion Prevention (fail2ban): To complement the firewall, Xavi.app integrates fail2ban for automated security against brute-force attacks. Fail2ban monitors service logs (SSH, API authentication, etc.) and will dynamically insert nftables rules to ban IP addresses that show malicious behavior (such as repeated failed login attempts) digitalocean.com. For example, an attacker trying to brute-force SSH into a VM or the management node will be blocked for a configurable period after a few failures, significantly reducing the risk of intrusion. This mechanism operates continuously in the background and updates firewall rules in real time, augmenting static firewall policies with adaptive defense.

Combined, these networking tools give the platform a strong security posture and agility. Administrators can reconfigure networks or firewall rules on the fly (useful for setting up new project environments or isolating a compromised host) with minimal disruption. The use of straightforward YAML and scripting for netplan and nftables also means configuration is automatable and can be checked into version control – aligning with modern DevOps practices.

Management Interface and User Portal

Xavi.app provides a rich web-based interface for both end-users and system administrators to interact with the platform. This is achieved by integrating a content management system (CMS) for the user portal, a single-page application for dynamic controls, and the Cockpit server console for low-level management:

ConcreteCMS Portal: The front-end website and user portal are built on ConcreteCMS (formerly Concrete5), a free open-source CMS known for its ease of use en.wikipedia.org. ConcreteCMS powers the informational pages, documentation, and account management interfaces of Xavi.app. It allows the platform developers to quickly publish content or updates (for example, announcing new features or maintenance schedules) and manage user sign-ups or support tickets through a familiar web interface. The choice of ConcreteCMS ensures that non-technical stakeholders (e.g. content editors or support staff) can contribute to the portal without needing to know the underlying codebase. The CMS is hosted on an Nginx web server with PHP 8.3-FPM, enabling fast delivery of pages and API calls. PHP 8.3 provides improved performance and security for the portal’s backend logic, while Nginx acts as a reverse proxy and static file server to efficiently handle large numbers of concurrent sessions.
Single-Page Application (SPA) Control Panel: For interactive control of resources – such as deploying a VM or monitoring GPU usage – Xavi.app includes a custom single-page web application. This SPA is integrated into the portal (it may be embedded as a dashboard section within ConcreteCMS, or served as a separate front-end that communicates with the backend via APIs). Using modern web technologies (e.g. a JavaScript framework), the SPA provides a responsive, dynamic interface where users can launch and manage compute instances in real time. For example, a user could select a desired GPU type and memory size, click “Deploy,” and the SPA will call Xavi.app’s backend APIs to spin up a VM or container accordingly. The interface can then live-update with the status (using AJAX/WebSocket calls) and allow further actions like starting/stopping instances or viewing logs. This design gives users a cloud-like experience similar to major public clouds, but on a private platform. It abstracts the complexity of libvirt or Podman commands behind a user-friendly GUI. The SPA also enables integration of role-based access control and project-specific views – important for enterprise and research collaborations where multiple teams may use the platform concurrently.
Cockpit Web Console: For advanced management and troubleshooting, Xavi.app leverages Cockpit, an open-source web console for Linux systems blog.while-true-do.io. Cockpit is particularly useful for system administrators or power users who need direct access to the underlying host’s management features. Xavi.app includes Cockpit’s relevant modules, notably cockpit-machines (which exposes a UI for libvirt/QEMU virtual machines) and cockpit-podman (which provides a UI for managing containers and pods). Through Cockpit, an admin can log in (using proper credentials) and see the low-level status of the host: current VM instances, their CPU/memory usage, container lists, storage volumes, network interface statistics, and even system logs. Crucially, Cockpit operates in real-time by interfacing with system APIs (systemd, libvirt, etc.) and does not require its own database blog.while-true-do.io. This means any changes made via Cockpit (such as creating a VM or stopping a container) are immediately reflected on the system, and vice versa – actions performed through other means (CLI or the SPA) will show up in Cockpit’s interface. Xavi.app can thus use Cockpit as both a safety net (allowing manual intervention if the higher-level tools encounter issues) and as an integration point – for example, scripting Cockpit’s APIs for automated provisioning, or embedding parts of Cockpit UI into the portal for advanced user roles. The Cockpit service runs behind the scenes, and Xavi.app can optionally proxy it through Nginx (or expose it on a secure port) for authorized access. Its inclusion underscores the platform’s commitment to using established open-source admin tools rather than reinventing the wheel.

Overall, the combination of ConcreteCMS + SPA for the end-user portal and Cockpit for system admin tasks creates a layered interface strategy. Everyday users (like researchers launching AI jobs) get a polished, simplified web experience, while developers and admins retain full visibility and control via Cockpit when needed. All web interfaces are secured via HTTPS (with Nginx handling SSL/TLS), and can be accessed through standard browsers, making the platform accessible remotely while maintaining security best practices.

Federated Communication via Matrix

A distinguishing feature of Xavi.app is its integration of the Matrix protocol for communication and collaboration. Matrix is an open standard for decentralized, end-to-end encrypted messaging, and Xavi.app leverages it to provide both users and administrators with a secure communication channel that is independent of proprietary platforms. Key points of this integration include:

Secure User Support and Collaboration: Rather than relying on traditional support tickets or insecure messaging, Xavi.app offers support and communication through a Matrix-based system. Users can join a Matrix room (or private support channel) to chat with Xavi.app engineers in real time xavi.app. This means that when issues arise or help is needed, communication is immediate and encrypted from end to end – only the user and the support engineer can read the messages, not even the server operators (thanks to Matrix’s cryptographic E2EE design). By using Matrix, Xavi.app can also federate this support channel: external collaborators (for instance, a research partner from a government lab that has its own Matrix server) can be invited into the conversation without forcing them onto a new platform. This model of support via Matrix contrasts with public cloud providers, where support often means waiting in ticket queues or using siloed chat systems xavi.app.
End-to-End Encryption and Privacy: Matrix was chosen for its strong security properties. All Matrix communications in Xavi.app’s setup support end-to-end encryption (using protocols like Olm/Megolm), ensuring that sensitive information (such as configuration details, code snippets, or credentials shared during troubleshooting) remains confidential element.io. Even if the Matrix server (homeserver) were compromised, the content of E2EE messages cannot be read by an attacker, which is a critical requirement for government and enterprise users. This level of security is one reason Matrix has been widely adopted by secure institutions – for example, multiple NATO member governments use Matrix-based messengers for internal communication, and the protocol is recognized for its interoperability and sovereignty (each organization can run its own server) element.io element.io. Xavi.app aligns with these best practices by giving its users a communication tool that meets government-grade privacy standards.
Federation and Integration: The Matrix protocol’s federated nature means Xavi.app’s communication system is not a closed silo. The platform likely runs its own Matrix homeserver (such as Synapse or a lightweight alternative) to host the chats. Users can connect using any Matrix client (e.g. Element, which is the reference client) on desktop or mobile. Because of federation, a user with an existing Matrix ID (say from an academic institution or NRC’s own Matrix service) could join Xavi.app rooms without creating a new account, if permitted. This opens possibilities for cross-organization collaboration: e.g., a project team spread across a university and a government agency could have a joint Matrix room for their Xavi.app cluster, enhancing coordination while keeping data within their control. Additionally, Matrix can be used for internal system notifications – for instance, the platform could send alerts to an admin’s Matrix account if a job finishes or if a system anomaly is detected. Using Matrix as a backend for such notifications taps into a rich ecosystem (bots and integration bridges exist to link Matrix with monitoring systems, email, etc.). The decision to use Matrix underscores Xavi.app’s commitment to open standards and user autonomy in communication.

In summary, the Matrix integration provides Xavi.app with a modern, secure communication backbone that benefits both the users (through real-time support and collaboration) and the operators (through secure, auditable channels for internal coordination). It complements the technical infrastructure by ensuring that human communication around the AI workflows is as resilient and private as the data processing itself.

Hardware Acceleration and Peripheral Passthrough

AI and machine learning workloads are highly dependent on specialized hardware like GPUs (graphics processing units) and high-speed storage. The Xavi.app platform is designed to fully exploit such hardware by allowing passthrough capabilities in both its VM and container environments:

GPU Passthrough to Virtual Machines: Xavi.app’s virtualization stack (libvirt + QEMU/KVM) supports PCI Express device passthrough, which enables a physical GPU to be directly assigned to a particular virtual machine. Using technologies like VFIO (Virtual Function I/O), the platform can attach a GPU or other PCIe device exclusively to a VM, so that the guest OS can use the device with near-native performance bdrsuite.com. For example, a researcher spinning up a VM with an NVIDIA A100 GPU will have full control of that GPU inside the VM, as if it were installed on a bare-metal machine. This is crucial for training deep learning models, as it provides hardware acceleration with negligible overhead and allows use of NVIDIA’s drivers and CUDA toolkit inside the VM. Xavi.app can similarly passthrough other devices – such as specialized AI accelerators, high-speed NICs, or storage controllers – if the use case requires. The ability to do this stems from QEMU/KVM’s mature support for device passthrough (which includes interrupt remapping, IOMMU isolation, and other low-level mechanisms to safely dedicate hardware to VMS bdrsuite.com). In practice, Xavi.app’s administrators prepare host servers such that each GPU can be isolated and mapped to VMs on demand. This gives the platform a significant performance advantage for heavy workloads: users get the full computational power of GPUs for training or inference, without the noisy neighbor problems or abstraction penalties that might come from virtualization of GPUs.
GPU Access in Containers: When running containerized workloads, Xavi.app similarly ensures that GPUs can be utilized within containers. Podman (and Docker-compatible runtimes) allow devices from the host to be exposed to containers. Xavi.app supports the use of NVIDIA’s Container Toolkit (or equivalent for AMD GPUs), so that a container can directly leverage GPU drivers. In practical terms, this means a user can pull a Docker image (for example, a TensorFlow or PyTorch image with GPU support), run it on Xavi.app’s container platform, and execute GPU-accelerated code seamlessly. The container sees the GPU (or a fraction of it, if using NVIDIA MIG or other slicing) as if it were on the host. This approach is key for Inference-as-a-Service offerings: the platform can run multiple containerized inference servers on different GPUs concurrently, each isolated in its container but getting full hardware speed for model execution. Additionally, because containers are lighter weight than VMs, Xavi.app can rapidly start and stop AI inference jobs in containers to scale with demand, all while using GPU passthrough or sharing as appropriate.
High-Speed Storage and Network I/O: Beyond GPUs, Xavi.app can passthrough or otherwise optimally expose other peripherals. For instance, if a user needs direct access to an NVMe SSD (for high I/O throughput on a database or for a local scratch disk in training), the platform can assign a physical NVMe device or a high-performance logical volume to that user’s VM. Storage controllers or HBAs (Host Bus Adapters) could be attached to VMs in specialized cases (e.g., connecting to a SAN or a tape library for archival data). On the networking side, technologies like SR-IOV (Single-Root I/O Virtualization) are used to give VMs or containers near-native network performance by provisioning virtual functions of a 10GbE/100GbE NIC directly to the instances. This ensures that data-intensive AI workloads – which often need to stream large datasets or checkpoint files – are not bottlenecked by virtualization overhead. In summary, the system is architected such that compute and I/O hardware can be utilized to its fullest by the workloads, whether they run in a VM or container environment.

The hardware passthrough capabilities position Xavi.app as a true AI compute cluster rather than a generic cloud service. Researchers and engineers can run GPU-accelerated training, real-time inference, or big data processing with confidence that the underlying hardware is dedicated to them and performing at peak capacity. This design choice is especially important for AI model development where training times and throughput directly impact productivity. By combining open-source virtualization with careful hardware management, Xavi.app achieves the goal of delivering flexible AI compute without sacrificing performance.

Conclusion

Xavi.app’s architecture demonstrates how a cohesive integration of open-source technologies can deliver a powerful, flexible AI infrastructure platform. By using industry-standard components (from KVM and libvirt to Podman, Nginx, and ConcreteCMS), the system is both transparent and extensible – internal stakeholders can audit and tweak any layer, while external researchers benefit from the familiarity and robustness of these tools. The platform’s support for both virtual machines and containerized workloads, across multiple Linux distributions, provides unparalleled versatility:
it can function as a private cloud for infrastructure provisioning, a ready-to-use environment for AI development, and a scalable service delivery platform all at once xavi.app.

Key technical advantages of Xavi.app include its modern network and security stack (netplan facilitating easy reconfiguration, nftables ensuring atomic and high-performance firewall policies, and fail2ban adding adaptive protection), and its commitment to secure communication through Matrix (reflecting best practices embraced by government and defense for protecting data-in-transit element.io). The platform’s web interface strategy – blending a user-friendly CMS/SPA portal with the potent Cockpit admin console – means it can cater to a broad audience, from non-expert users launching AI jobs via one-click UI to seasoned system administrators fine-tuning the cluster’s operations.

In delivering a “secure, low-cost AI backbone” that is private and compliant with data sovereignty requirements, Xavi.app aligns well with the needs of research institutions and government bodies. All compute and data remain on Canadian soil (in Tier III green-energy data centers), which is ideal for sensitive projects under privacy laws or national research mandates xavi.app. Furthermore, the exclusive use of open-source software ensures that agencies like the National Research Council can evaluate the platform without proprietary black boxes, fostering trust and facilitating collaborative development (e.g., adding new features or integrating with existing open systems).

Moving forward, Xavi.app is positioned to adapt and grow by the very virtue of its flexible architecture. Emerging capabilities – such as federated learning support or edge AI deployment – can be incorporated by extending the same open-source toolkit (for example, leveraging Kubernetes for multi-site orchestration or adding new Cockpit plugins for edge nodes). The platform exemplifies a modern, modular approach to AI infrastructure: built on open standards, optimized for performance, and designed for the stringent security and compliance demands of today’s AI landscape. It serves as a solid foundation for any organization seeking to harness AI compute power while retaining full control over their infrastructure.

Sources:

Xavi.app About – Company background and service offerings xavi.app xavi.app.
BDRSuite Technical Blog – Explanation of QEMU/KVM virtualization and libvirt management layer bdrsuite.com bdrsuite.com.
WhileTrueDo Blog – Cockpit and Podman integration for container management blog.while-true-do.io blog.while-true-do.io.
DigitalOcean Tutorial – Fail2ban usage for firewall-based intrusion prevention digitalocean.com.
Ubuntu Documentation – Netplan with NetworkManager, applying YAML network configs on the fly documentation.ubuntu.com.
Red Hat Developer – nftables modern firewall advantages (atomic rule updates) developers.redhat.com.
Element/Matrix News – Adoption of Matrix by secure institutions (NATO allies, DoD) and its E2EE capabilities element.io element.io.
ConcreteCMS Wikipedia – Confirmation of ConcreteCMS as an open-source CMS platform github.com.