tiCrypt Is Hardware Agnostic: What Actually Matters
tiCrypt has no hardware vendor lock-in. It runs on commodity x86_64 servers, standard networking, and whatever storage you already have. But "hardware agnostic" does not mean "no requirements."
What "Hardware Agnostic" Means
tiCrypt's backend is a set of Linux services. VM hosting uses standard KVM/libvirt. If a machine runs RHEL, Rocky Linux, or AlmaLinux and has CPU virtualization extensions, it can host tiCrypt.
Storage works the same way. tiCrypt keeps VM images and drives as files in libvirt directory pools, so any storage the VM hosts can mount as a file system works (local disk, NFS, CephFS, BeeGFS, Lustre). It encrypts inside the VM with LUKS or BitLocker, not at the storage layer. Among those file systems, storage is a performance choice, not a compatibility one.
On-premises, colocation, and cloud bare-metal all work. That is a statement about compatibility, not about compliance scope. For CUI, the servers and storage that hold tiCrypt data are inside the assessment scope whether or not that data is encrypted, and a cloud provider that hosts them must meet the FedRAMP Moderate baseline or its equivalent (CMMC FAQ, July 2026, questions B-Q8, E-Q1 and E-Q2). The Infrastructure Overview covers the modular architecture.
Hard Requirements
Without these, tiCrypt will not run.
| Requirement | Why |
|---|---|
| x86_64 CPU | tiCrypt binaries, and the VM definitions tiCrypt generates, are x86_64 only |
| VT-x or AMD-V enabled | KVM needs hardware virtualization support |
| RHEL, Rocky, or AlmaLinux (8, 9, or 10) | The only supported host operating systems |
| VLAN-capable switches (multi-host) | Open vSwitch bridges isolate VM traffic across VLANs between hosts; a single server needs none |
| Shared filesystem (multi-host) | VM images, drives, and project data must be accessible from all hosts (any implementation: NFS, Ceph, GlusterFS, etc.); a single server can use local storage |
Any modern rack server or cloud bare-metal instance meets these. See the Infrastructure Overview for sizing and the Pre-Installation Checklist for everything that must be ready before installing.
Hardware Depends on the Research Workflow
Meeting the hard requirements gets a deployment running. Running it well depends on the workload.
A social science team reviewing survey data in a Windows desktop needs responsive storage and a smooth display. A bioinformatics group running alignment jobs across Slurm nodes needs raw compute, memory, and filesystem throughput. No single spec fits both.
Denser nodes help in both cases: more cores, more memory, local NVMe storage. Multi-GPU nodes handle accelerated workloads through PCI passthrough.
Our deployments range from NVIDIA DGX SuperPODs with InfiniBand and parallel storage to a single server with a few dozen cores and a terabyte of local disk.
What Shapes Performance
None of these block an install, but they shape what researchers experience.
Distributed Filesystem
Every VM reads and writes through the shared filesystem. In multi-host deployments, this is the most common bottleneck. Performance comes down to storage IOPS and the network speed between VM hosts and the filesystem. NVMe is far faster than spinning disk, but even fast storage can be choked by a slow network path. See Libvirt Storage Pools and Filesystem Interplay.
Network Speed
The network carries filesystem traffic, VM-to-backend communication, connection tunnels, and inter-node MPI traffic for Slurm workloads. Plan for 10 GbE or faster in production.
GPU Passthrough
Only relevant for GPU workloads (ML, visualization). Requires IOMMU (Intel VT-d or AMD-Vi) enabled in BIOS. Most modern servers have this already.
Memory Sizing
KVM can overcommit RAM, trading density for contention risk. Physical memory needs depend on VM count and concurrency. See the Infrastructure Overview.
Encryption and Virtualization Overhead
Both are negligible on modern hardware.
Encryption. tiCrypt encrypts VM drives (LUKS/BitLocker), network tunnels, and all data at rest. Every modern x86_64 CPU includes AES-NI, which handles encryption in hardware. LUKS-encrypted drives add no measurable latency over unencrypted drives, even at the 99th percentile. This holds in FIPS mode too.
Virtualization. KVM is a Type-1 hypervisor in the Linux kernel with hardware-assisted VM entry/exit. Overhead is typically 5-10%. For tightly coupled MPI jobs, bare-metal container execution is planned; see Bare-Metal Slurm.
What Doesn't Matter
- Server brand or OEM
- CPU generation (anything with VT-x/AMD-V from the last decade)
- On-premises, colo, or cloud (for CUI, a cloud provider must still meet the FedRAMP Moderate baseline or its equivalent)
- NIC vendor or chipset
- Storage vendor or RAID controller
- Distributed filesystem implementation (NFS, Ceph, GlusterFS all work)
tiCrypt depends on standard Linux and KVM primitives, not vendor-specific integrations.
Start with the Pre-Installation Checklist, then the Backend Installation Guide. See the Infrastructure Overview for sizing.
Related: Backend Installation Guide | Infrastructure Overview | OpenVSwitch Networking | Libvirt Storage Pools | Bare-Metal Slurm