Security isn't a department — it's an engineering discipline. Here's our four-layer defense architecture, from edge filtering to disk encryption, and why we skip the compliance theater.
When we architect security for a hosting platform, we don't start with a compliance checklist. We start with the adversary. Our threat model assumes three types of attackers: external actors attempting to reach customer data through the network, malicious co-tenants attempting to escape VM isolation on shared hardware, and insider threats from compromised credentials or supply chain attacks on our own tooling.
Each of these threats requires different defenses, and no single control addresses all of them. That's why we use defense-in-depth — four distinct security layers, each independently capable of stopping an attack even if the layer above it has been compromised.
Every packet entering our network passes through hardware-accelerated filtering at the edge before it reaches any customer infrastructure. This layer handles volumetric DDoS attacks, SYN floods, UDP amplification, and IP reputation filtering. It operates at line rate with less than 1ms of added latency because the filtering logic runs on FPGA-based SmartNICs rather than in software.
The edge layer drops approximately 14 billion malicious packets per day across our fleet. Customers don't configure this layer and can't disable it — it's always on, because the one time someone disables DDoS protection "temporarily" is always the time they get hit.
Every customer gets a dedicated firewall instance with default-deny inbound rules. The firewall runs on dedicated hardware separate from the hypervisors, so a compromised VM can't reach the firewall control plane. All inter-customer traffic is isolated at Layer 2 using 802.1Q VLANs — customers on the same physical host cannot see each other's network traffic, even with promiscuous mode enabled in their VM.
For customers using our private networking feature, traffic between their servers travels over encrypted tunnels (WireGuard) even within the same data center. We encrypt intra-DC traffic because physical security assumptions break down at scale — with thousands of network cables in a facility, we can't guarantee that every single patch isn't being tapped.
# Default firewall rules (applied automatically)
Chain INPUT (policy DROP)
ACCEPT state RELATED,ESTABLISHED
ACCEPT icmp type echo-request limit 10/sec
ACCEPT tcp dpt:22 # SSH (customer can restrict further)
DROP all
Chain FORWARD (policy DROP)
# No inter-customer forwarding everOur VPS instances run on KVM with hardware-assisted virtualization (Intel VT-x / AMD-V). Each VM gets its own isolated memory space enforced by the CPU's memory management unit — this is a hardware boundary, not a software one. Even if our hypervisor software had a bug, the CPU would prevent one VM from reading another VM's memory.
All host storage is encrypted with LUKS2 using AES-256-XTS. Encryption keys are stored in the server's TPM (Trusted Platform Module) and are only released after the server passes secure boot attestation. If someone physically removes a drive from one of our servers, the data is unreadable without the TPM.
We also run a custom hardened kernel on all hypervisors. The kernel has approximately 340 syscalls disabled that aren't required for hosting workloads, reducing the attack surface for kernel exploits. We patch kernels within 72 hours of any CVE rated 7.0+ on the CVSS scale, using kexec for zero-downtime updates.
Every piece of software that runs on our infrastructure is built from source in our own CI pipeline. We don't download pre-built binaries from upstream projects — we clone the source, verify the commit signature against a pinned GPG key, build in an isolated container, and produce a reproducible binary. If the binary doesn't match the expected hash, the build fails.
For firmware (BIOS, BMC, NIC), we verify signatures against the vendor's public key before any update. We also maintain a "known good" firmware inventory — if a server's firmware hash doesn't match our expected version, it's automatically quarantined until manually inspected.
14B malicious packets blocked0 VM escape incidents (lifetime)
72hr max kernel patch time100% disk encryption coverage
SOC 2 Type II certifiedAnnual third-party pentest
We hold SOC 2 Type II certification and complete annual third-party penetration tests (currently conducted by NCC Group). Our pentest reports are available to customers under NDA — we publish the executive summary and remediation status publicly on our security page.
We deliberately avoid collecting compliance certifications that we don't believe add real security value. We'd rather invest engineering time in actual security controls than in documentation for auditors. When a customer asks "are you ISO 27001 certified?" we say no, but here's what we actually do, and here's our pentest report — you tell us if that's sufficient for your threat model.