RemoteRails

Reference Architecture: Dedicated Tier

Sovereign Comms Appliance

This document outlines the baseline logical and physical architecture for the dedicated Sovereign Comms Appliance. It details the hypervisor control plane, storage cryptography boundaries, and the functional isolation of virtualized workloads across a bare-metal environment.

📌 Scope of Architecture: Dedicated Bare-Metal vs. Cloud Instances The architecture and cryptographic boundaries detailed in this document apply exclusively to our Dedicated Bare-Metal (Tier 1) product line. It does not apply to our Cloud / VPS product tiers, as shared virtualization environments do not provide the necessary low-level access to the physical memory controller or host BIOS required to enforce these specific security primitives.

This Tier 1 deployment utilizes transparent, host-level memory encryption (AMD SME / Intel TME) to secure data in transit across the physical RAM bus. It does not utilize guest-level cryptographic VM enclaves (Tier 2: AMD SEV-SNP / Intel TDX), ensuring the hypervisor retains maximum throughput and thin-provisioning efficiency. Because it strikes the optimal balance between absolute physical security, high-performance virtualization, and operational scalability, this Dedicated tier is our baseline recommendation for most midmarket businesses.

📌 Important Note on Resource Allocation The architecture detailed on this page is an illustrative example based on a high-efficiency 12-thread / 32GB RAM / 512GB NVMe hardware profile. Exact storage partitioning, CPU weighting, and memory allocations are dynamically calculated based on the specific physical server provisioned for your deployment. For paying customers, our infrastructure architects provide direct consultation to tailor resource allocation matrices to your specific operational threat model and workload requirements.

Architecture Topology

The dedicated Sovereign Comms Appliance enforces a strict boundary between the hypervisor management layer and guest execution environments. Workloads are segmented into distinct virtual machines (VMs) to isolate public ingress (Edge), real-time communication (Core), and object storage (Sovereign Storage).

========================================================================================
                                BARE-METAL HARDWARE POOL
 [ 12 CPU Threads (AMD Ryzen Pro or Epyc) ]                      [ 32 GB RAM ]
 
 [ HIGH-IOPS SSD ARRAY ]                                    [ MASS STORAGE HDD ARRAY ]
 [ 2 x 512GB NVMe SSDs  ]                                    [ 4 x 6TB SATA/SAS HDDs  ]
 [ Configured as RAID 1 ]                                    [ Configured as RAID 10  ]
 [ Usable: 512GB        ]                                    [ Usable: 12TB           ]
========================================================================================
                                       │
========================================================================================
                     PROXMOX VE HYPERVISOR CONTROL PLANE
                     (LUKS2 ENCRYPTED UNDERLYING STORAGE POOLS)
[ 512GB NVMe Array ] ──► [ LUKS2 Container ] ──► [ Volume Group / Thin Pool ] (40GB Host OS)
[ 12TB HDD Array   ] ──► [ LUKS2 Container ] ──► [ Volume Group / Thin Pool ] (Thick or Thin)
========================================================================================
                                       │
         ┌─────────────────────────────┼─────────────────────────────┐
         ▼                             ▼                             ▼
┌─────────────────────────┐   ┌─────────────────────────┐   ┌─────────────────────────┐
│  VM 1: EDGE GATEWAY     │   │  VM 2: CORE SERVICES    │   │  VM 3: SOVEREIGN STORAGE│
├─────────────────────────┤   ├─────────────────────────┤   ├─────────────────────────┤
│ • CPU:  2 vCPUs         │   │ • CPU:  8 vCPUs (W:2048)│   │ • CPU:  6 vCPUs (W:1024)│
│ • RAM:  2 GB            │   │ • RAM:  12 GB           │   │ • RAM:  16 GB           │
│ • SSD:  20 GB (Standard)│   │ • SSD:  350 GB(Standard)│   │ • SSD:  80 GB (Standard)│
│                         │   │   (App, Message Index,  │   │   (OS, DB Core,         │
│                         │   │    Mail Store, NVMe DBs)│   │    Thumbnail Cache)     │
│ • HDD:  0 GB            │   │ • HDD:  2 TB (Standard) │   │ • HDD:  10 TB (Standard)│
│                         │   │   (Media & Attachments) │   │   (Raw Data Mount)      │
├─────────────────────────┤   ├─────────────────────────┤   ├─────────────────────────┤
│ OS LAYER (NO LUKS):     │   │ OS LAYER (NO LUKS):     │   │ OS LAYER (NO LUKS):     │
│ - Standard LVM (ext4)   │   │ - Standard LVM (ext4)   │   │- Standard LVM (ext4/XFS)│
├─────────────────────────┤   ├─────────────────────────┤   ├─────────────────────────┤
│ WORKLOADS:              │   │ WORKLOADS:              │   │ WORKLOADS:              │
│ - Traefik Proxy         │   │ - Matrix Server         │   │ - Nextcloud Core        │
│ - TLS Termination       │   │ - Stalwart Mail Engine  │   │ - PostgreSQL Database   │
│                         │   │ - Vaultwarden           │   │ - Redis File Caching    │
│                         │   │ - LiveKit SFU Media     │   │                         │
└─────────────────────────┘   └─────────────────────────┘   └─────────────────────────┘
 │
 ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ PROXMOX VE HYPERVISOR HOST CONTROL PLANE (MANAGEMENT LAYER)                         │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ • CPU: Shared natively across all threads. (Uses 0% when VMs are idle).             │
│ • RAM: 2 GB explicitly reserved for Host OS overhead, networking tables, and ZFS.   │
│ • SSD: 40 GB used for Root Host Filesystem (`/`), leaving ~22GB unallocated buffer. │
└─────────────────────────────────────────────────────────────────────────────────────┘

Physical Storage Redundancy & RAID Architecture

To guarantee high availability and protect against physical drive failure, the appliance does not rely on single points of failure for storage. The usable capacities detailed in the architecture topology are backed by robust, hardware-level or ZFS-based RAID arrays that sit beneath the LUKS encryption layer.

The High-Performance NVMe Pool: RAID 1 (Mirroring)

  • Physical Hardware: 2 x 512GB NVMe SSDs.
  • Usable Capacity: ~512GB.
  • The Architecture: The drives are configured in a strict RAID 1 mirror. Every block written to the primary SSD is simultaneously cloned to the secondary SSD.
  • The Operational Benefit: This array houses the Proxmox hypervisor root, the Edge Gateway, and the highly transactional Core Services databases (Matrix, Stalwart, Vaultwarden). If a primary NVMe drive suffers catastrophic silicon failure, the system continues to operate seamlessly with zero downtime and zero data loss. RAID 1 also effectively doubles read performance, as read requests can be distributed across both NVMe controllers.

The High-Capacity Storage Pool: RAID 10 (Stripe of Mirrors)

  • Physical Hardware: 4 x 6TB SATA/SAS HDDs.
  • Usable Capacity: ~12TB.
  • The Architecture: The drives are configured in a RAID 10 topology. The four drives are split into two mirrored pairs (RAID 1), and data is then striped across those two pairs (RAID 0).
  • The Operational Benefit: Nextcloud object storage and large mail directories require a delicate balance of massive capacity, fault tolerance, and disk I/O performance. RAID 10 provides the fastest possible read/write speeds for mechanical drives because it avoids the heavy CPU parity-calculation overhead associated with RAID 5 or RAID 6. Furthermore, it allows the array to survive the total failure of up to two drives (one in each mirrored pair) while maintaining rapid, penalty-free rebuild times when a drive is replaced.

Cryptographic Pipeline Note: The RAID aggregation occurs before the cryptographic boundary. The hypervisor presents the unified RAID 1 and RAID 10 volumes to the dm-crypt module, meaning the LUKS2 container encrypts the entire aggregated array as a single, contiguous block device.

Physical Hardware & Cryptographic Boundary

To prevent the performance degradation associated with virtualized double-encryption (running encrypted file systems inside encrypted virtual disks), cryptography is strictly enforced at the bare-metal level.

  • Host-Level LUKS2 Encryption: Both the NVMe SSD and SATA/SAS HDD pools are encrypted using LUKS2 (dm-crypt) directly on the Proxmox VE host. Keys are managed at the host level, ensuring that if physical drives are removed from the chassis, all data remains cryptographically inaccessible.
  • Hardware Memory Encryption (SME/TME): At the BIOS and CPU level, the host enforces Secure Memory Encryption (AMD SME) or Total Memory Encryption (Intel TME) to protect physical RAM modules from cold-boot and side-channel extraction attacks without penalizing virtualization efficiency.
  • Guest-Level Plaintext LVM: Because the underlying hypervisor storage and memory buses are secured physically, the guest OS layers (VM 1, 2, and 3) utilize standard, unencrypted ext4/XFS file systems over LVM. This preserves SSD thin-provisioning capabilities and eliminates cryptographic CPU overhead for high-throughput workloads (like LiveKit media routing or database writes).

Virtual Machine Segmentation

The appliance utilizes logical segmentation to limit the blast radius of potential exploits and guarantee resource availability for critical processes. By strictly managing the 512 GB NVMe block allocations, we ensure high-IOPS availability where it is most needed without starving the hypervisor.

VM 1: Edge Gateway

This VM functions as the primary perimeter defense and reverse proxy layer. It operates with minimal privileges and strict storage quotas.

  • Role: Ingress controller, Layer 7 routing, and TLS termination.
  • Workload: Traefik Proxy.
  • Resource Profile: Minimal allocation. 2 vCPUs assigned with a low scheduler priority, as network I/O and TLS offloading require minimal compute overhead. The 20 GB SSD allocation is more than sufficient for a stateless proxy layer.

VM 2: Core Services

This is the high-performance compute node for synchronous real-time communication and identity workloads. It requires substantial NVMe storage capacity to handle transactional application databases within the constrained SSD pool.

  • Role: Unified communications, identity management, database indexing, and credential storage.
  • Workloads: Matrix Homeserver (RocksDB/Postgres), Stalwart Mail Engine (Raw Mail Directory & RocksDB), Vaultwarden, LiveKit SFU.
  • Resource Profile: Heavy compute and high-IOPS storage allocation. Configured with 8 vCPUs and a proportional CPU weight of 2048. By allocating 350 GB of the primary NVMe tier, this VM has ample capacity to absorb the dense write paths, indexing structures, and message states inherent to concurrent mail and chat protocols, ensuring long-term database stability.

VM 3: Sovereign Storage

Designed for asynchronous data workloads, heavy database queries, and object storage management.

  • Role: Private cloud storage, document sync, and relational databases.
  • Workloads: Nextcloud Core, PostgreSQL, Redis (Memory/File Caching).
  • Resource Profile: Heavy memory and storage allocation. Operating systems, application databases, and performance-critical directories reside on an optimized 80 GB SSD logical volume. This allocation safely accommodates Nextcloud’s core structural requirements and thumbnail caching, while the actual raw user data files are offloaded to the high-capacity HDD pool (12 TB). CPU weight is set to 1024, allowing background file syncs to utilize idle host CPU without starving the real-time services on VM 2.

Hypervisor Control Plane Reservations

To ensure absolute stability of the virtualization environment, the Proxmox VE host explicitly reserves resources that cannot be consumed by the guest VMs.

  • Memory Reservation: A hard limit of 2 GB RAM is fenced off for the Host OS, Open vSwitch networking tables, and base-level hypervisor operations.
  • Storage Allocation: 40 GB of the primary NVMe SSD thin pool is reserved for the Proxmox Root Filesystem (/) to accommodate ISO images, container templates, and host-level log retention. (This layout reserves roughly ~22 GB of unallocated SSD space at the LVM physical volume level, preventing critical volume metadata exhaustion).